Oracle内核系列3-揭秘ASM磁盘头信息
转载声明：本文为DBA+社群原创文章，转载必须连同本订阅号二维码全文转载，并注明作者名字及来源：DBA+社群（dbaplus）。
专家简介
马育义
【DBA+社群】广州群副
拥有5年DBA运维经验，精通Oracle数据库管理，深入理解Oracle 体系结构，擅长使用RAC、Dataguard、Goldengate等技术解决Oracle数据库运维故障。精通Oracle数据库安装配置、性能诊断、故障处理、备份解决方案的设计与实施。Oracle OCP认证讲师，在Oracle OCP和OCM的培训方面也有较为丰富的经验，曾多次负责广东移动、深圳航空的DBA培训工作。
1.1基础概念
1.1.1 ASM File
从10g开始，数据文件的存储除了使用裸设备和文件系统外，还可以存放在ASM中。简单的理解，存放在ASM中的数据文件，日志文件，控制文件，归档日志等等，就是ASM FILE。仅有以下的文件类型可以存放在ASM Diskgroup中：
Control File
Datafile
Temporary data file
Online Redo Log
Archive Log
RMAN backup
Datafile Copy
SPFILE
Disaster Recovery Configuration
Flashback Log
Change Tracking Bitmap
DataPump Dumpset
一个ASM FILE的名字一般以一个”+”和DiskGroup名字开头。 当ORACLE RDBMS KERNEL内核的文件I/O层碰到一个以”+”开头的文件时，就会走到相关ASM的代码层中 而不是调用依赖于操作系统的文件系统I/O。 仅仅在File I/O层面才会认识到这是一个ASM 中的文件，而其上层的内核代码看来ASM FILE和OS FILE都是一样的。
举例：
+DATAA/orcl/datafile/system.256.689832921
格式说明: +DATA/orcl/datafile/tbs_name.asm_filenumber.incarnation_number
orcl:数据库名称
datafile: 文件类型，表示是数据文件
tbs_name: 表空间名
asm file#: 表示ASM file编号，$asm_file.file_number
incarnation number: 从时间戳提取，唯一值。
在一个ASM Diskgroup中仅仅允许存放已知的ORACLE文件类型。假设一个文件通过cp拷贝到ASM Diskgroup中，则该文件的第一个块将被检验以便确认其类型，以及收集其他信息来构建这个文件的完整ASM文件名。 如果其文件头无法被识别，则该文件在DiskGroup中的创建将会报错。
1.1.2 ASM AU
ASM在分配空间时，以AU为单位进行，AU即Allocation units，是组成ASM disk的基本单元。在Oracle 10gR2中，ASM AU的缺省单位大小是1M，相应的条带化大小是128K，可以通过调整_asm_ausize隐含参数来调整AU大小，调整_asm_stripesize控制相应的条带化大小。
11g后可以在创建磁盘组时可以配置AU 大小，AU的允许大小有1、2、4、8、16、32 或64 MB。
1.1.3 File Blocks
所有被ASM所支持的文件类型仍以其file block作为读和写的基本单位。在ASM中的文件仍保持其原有的 Block Size 例如数据文件默认为8k，ASM并不能影响这些东西。值得一提的是在ASM FILE NUmber 1 的FILEDIR中记录了每一种FILE TYPE对应的BLOCK SIZE。
1.1.4 ASM元数据
ASM的元数据都存储在ASM磁盘中，用以存放ASM Diskgroup控制信息的数据，Metadata包括了该磁盘组中有哪些磁盘，多少可用的空间，其中存放的File的名字，一个文件有哪些Extent等等信息。
元数据分成2类，一类是物理元数据（Physical Metadata），一类是虚拟元数据（Virtual Metadata）。物理元数据存储在磁盘的固定位置，通常在ASM磁盘头。虚拟元数据后者存储在ASM文件上，和常规的ASM File一样在所有磁盘之间均匀分布。事实上虚拟元数据也是当做一个个ASM File来维护的。
所有的元数据block均是4k大小，并且有checksum信息来确认block是否被损坏。
1.1.5 ASM磁盘头
一个ASM DISK的最前面4096字节为disk header，对于ASM而言是block 0 (blkn=0)。ASM disk header描述了该ASM disk和diskgroup的属性，通过对现有disk header的加载，ASM实例可以知道这个diskgroup的整体信息。所以对那些会影响ASM disk header的操作要慎之又慎，同时最好定期备份disk header。
1.2物理元数据
物理元数据存储在磁盘的固定位置，通常在ASM磁盘头，其由以下组成：
1.3逻辑元数据
物理元数据用于描述磁盘组的组成、空间分配等内容。而虚拟元数据则用于记录ASM文件在磁盘上的分布，虚拟元数据也存在于ASM文件当中，和其他ASM文件的分布和管理完全相同。虚拟元数据一般包含：
1.4元数据查询
1.4.1 通过File Directory查询
ASM的物理元数据都保存在AU 0和AU 1中，其他的虚拟元数据的位置要到File Directory去查询，该目录记录了所有ASM File的元数据，每个ASM File在它里面都有一条记录，它记录了每个ASM File的extent对应的disk number和au number。
File Directory的起始点存储在磁盘0的2号AU上面。2号AU总共有256个块。每一个块大概4KB。第0个块是用于文件头留用。从第1个块开始记录文件asm file number为1的磁盘分布信息，而第2个块开始记录asm file number为2的磁盘分布信息。以此类推，刚好从asm file number从1-255都保存在2号AU上面。所以File#1至少包含了2个AU，因为我们的数据库文件的file number是从256开始的。
想知道虚拟元数据的分布情况，就要先找到File#1的disk number和au number的分布信息，就需要读取0号磁盘的2号AU的第一个块。
Oracle提供了一个KFOD工具，10gR2以上都有自带，用于列举搜索磁盘。我们先看看测试环境中有哪些共享磁盘：
在我的测试环境中，磁盘组DATA有两个磁盘raw3和raw4：
ASM block的查看，Oracle提供了一个kfed工具。11g后可直接在oracle用户下使用，而10g则需要编译一下：
查找File#1的AU分布情况：
我们可以看到File#1有2个AU：
DISK 0，AU[2]
DISK 1，AU[2]
案例：查询控制文件的AU信息
现在我想查看控制文件的AU信息，先计算控制文件的AU信息在File Directory的哪个块：
接下来我们读取1号磁盘的2号AU的第4个块。这个AU是从块0来记录256号文件的。无需进行预留。为什么是第4个块？
260-255=5 默认从0号块开始，所以第4个块代表了260号文件
然后我们查出包括控制文件的AU信息。
最后我们找一个AU来确认一下是否是控制文件。我们用操作系统的dd命令读取0号文件的第834号AU信息。
1.4.2 通过X$KFFXP查询
通过视图X$KFFXP可以更直观地查看ASM file的物理分配AU情况。该视图主要是反映了File Extent Map的映射关系。ASM把文件分成多个Extent，而Extent是由AU构成的。
通过X$KFFXP和v$asm_alias、v$asm_disk、v$asm_diskgroup等相连，可以方便地查询到各个ASM File的AU分布情况：
2.1ASM磁盘头含义
ASM disk header描述了该ASM disk和diskgroup的属性，通过对现有disk header的加载，ASM实例可以知道这个diskgroup的整体信息。
下面是一个典型的disk header的组成：
下面的信息是在同一个diskgroup中的所有disk的header上均会复制一份的：
Disk group name and creation timestamp
Physical sector size of all disks in the disk group
Allocation unit size
Metadata block size
Software version compatibility
Default redundancy
Mount timestamp
下面的信息是每一个asm disk独有的：
ASM disk name (not OS path name)
Disk number within disk group
Failure group name
Disk size in allocation units
2.2磁盘头元数据校验
ASM磁盘头的查看，我们可以直接使用Oracle提供的kfed工具。
但是这样不一样能发现元数据有异常的情况，我们可以使用kfed find命令检验AU[0]所有块的元数据类型是否正常。如果出现非以下结果的块，说明ASM元数据块有所损坏。
注：以上只是检验元数据块的类型是否正常，如果元数据块中内容有误，目前还是没有办法可以直接检查出来。
2.3磁盘头的备份恢复
ASM磁盘头的重要性无庸置疑，通过观察ASM磁盘头各项含义后，我们发现ASM磁盘头并不类似其他ASM File一样经常变化修改，这使得对ASM磁盘头的备份具体有行性。
2.3.1 11.1.0.7之前
对于10.2 到11.1.0.6的ASM，磁盘头的备份方法就是dd或者kfed。
dd备份：
dd恢复演示：
1、模拟磁盘头损坏
此时再挂载磁盘组报错：
2、检查磁盘头内容
kfed检查ASM 磁盘头，Kfed输出显示磁盘头的信息全部都是0，说明ASM磁盘头被覆盖或损坏了。
3、使用前面的dd备份恢复
4、重新挂载磁盘组
kfed备份：
kfed恢复：
注意：如果既无dd备份也无kfed备份，则只能手动修复磁盘头，后面有详细介绍。
2.3.2 11.1.0.7之后
从10.2.0.5、11.1.0.7、11.2之后ASM磁盘头会自动备份到AU#1的倒数第二个block。对于AU size是1MB的DISKGROUP，每个AU包括block数量=1024KB/4KB=256个，因此备份信息位于AU#1的第254号block(block从0号开始)。当然可以计算得到：
查看ASM磁盘头备份信息，备份信息与ASM disk header信息完全一致（blk、check除外）：
因此可以直接使用kfed命令修复磁盘头。
1、模拟磁盘头损坏
此时再挂载磁盘组报错：
2、kfed修复磁盘头
3、查看新的磁盘头
2.4手工重构磁盘头
针对10g和11gR1，由于ASM没有自动备份磁盘头。在某些磁盘维护操作时很容易误删除磁盘头数据，此时就只能通过手工重构磁盘头。
重构磁盘头主要需要修改下列值：
kfbh.endian
kfbh.block.obj
kfdhdb.driver.provstr
kfdhdb.dsknum
kfdhdb.grptyp
kfdhdb.dskname
kfdhdb.grpname
kfdhdb.fgname
kfdhdb.crestmp.hi
kfdhdb.crestmp.lo
kfdhdb.mntstmp.hi
kfdhdb.mntstmp.lo
kfdhdb.dsksize
kfdhdb.fstlocn
kfdhdb.altlocn
kfdhdb.f1b1locn
kfdhdb.grpstmp.hi
kfdhdb.grpstmp.lo
当然还有些情况，需要具体问题具体分析，比如使用了11.2的版本的，就需要有VOTEDISK和SPFILE的那几个参数值，上面列出来的是针对10g和11gR1。
如1.3中所介绍的，Disk Directory包含大量磁盘头信息，是我们手工重构磁盘头的数据来源。而如果只是磁盘组中一块磁盘头损坏，则可以更加方便地参考其他正常磁盘头的信息。
在我的测试环境中，磁盘组DATA有两个磁盘raw3和raw4：
先暴力摧毁raw3的磁盘头：
我们先利用raw4生成一个磁盘头，再重构成raw3的磁盘头：
修改必要的值，与raw3的实际情况配合，以下是要修改的项。
修改/tmp/raw3.head后，写入到raw3的磁盘头中，重新挂载磁盘组成功。
即日起，凡是推送在【DBAplus社群】平台的文章，阅读量超过1000，该文章作者可获得赠书一本。大家如有好的干货文章也可以向我们的订阅号投稿，投稿邮箱：1017465571@qq.com。近期赠书有：白鳝《思想的天空》、杨志洪《Oracle核心技术》……
小编精心为大家挑选了近日最受欢迎的几篇热文：
回复001，看丁俊的《【重磅干货】看了此文，Oracle SQL优化文章不必再看！》；
回复002，看吕海波的《去不去O，谁说了算？》；
回复003，看胡怡文《PG，一道横跨oltp到olap的梦想之桥》；
回复004，看郭耀龙《假事务之名，深入研究UNDO与REDO》；
回复005，看杨志洪《【职场心路】一个老DBA的自白》；
回复006，看周俊《被埋没的SQL优化利器——Oracle SQL monitor》；
回复007，看袁伟翔《揭秘Oracle数据库truncate原理》；
回复008，看杨奇龙《数据库性能测试》；
回复009，看丁启良《LINUX类主机JAVA应用程序占用CPU、内存过高分析手段》；
回复010，看黎君原《扒一扒Oracle数据库迁移中的各种坑》。
DBA+社群是全中国最大的涵盖各种数据库、中间件及架构师线条的微信社群！有100+专家发起人，建有15大城市微信群，6大专业产品群，多达10000+跨界DBA加入队伍。每天1个热议话题，每周2次线上技术分享，不定期线下聚会与原创专家团干货分享，更多精彩，欢迎关注dbaplus微信订阅号！
扫码关注
DBAplus社群
超越DBA圈子，连接的不仅仅是DBA