ASM 翻译系列第十五弹:ASM Internal ASM File Directory

原作者:Bane Radulovic

译者: 郭旭瑞

审核: 魏兴华

DBGeeK社群联合出品

ASM File Directory

本篇主要介绍ASM的1号文件,ASM的1号文件是ASM的文件目录,它记录了磁盘组中的所有文件信息,由于在ASM中,每一个磁盘组都是独立的存储单元,所以每一个磁盘组都会有属于它自己的文件目录。

虽然这是一个内部的文件,但ASM实例会把它当做其它ASM文件一样管理,在ASM的文件目录中也会有它自己的条目(指向了它自己),在一个normal和high冗余的磁盘组中,它也会做镜像,随着新文件的产生,文件目录的大小也会相应地增长。

每一个ASM文件目录的条目都会包含如下的信息:

● 文件大小

● 文件块大小

● 文件类型

● 文件的冗余级别

● 文件的条带配置

● 前60个extent的位置指针

● 如果文件超过60个extent,那么会有Indirect extent 的指针

● 文件创建时间戳

● 文件最后的修改时间戳

● 指向ASM Alias目录的文件名

每个新增加的ASM文件会分配到一个号码,这个号码是随着新增文件而顺序递增的。文件的号码与文件目录中的block号码也是完全对应的,也就是说,文件目录的1号block描述了他自己也就是1号文件的信息。2号block是描述2号文件的,300号block是描述300号文件的,4000号block是关于4000号文件的,以此类推。如下,是ASM的257号文件,kfbh.block.blk指出了文件目录里块的编号,此编号也是文件的编号。

kfed read /dev/qdata/vdf aun=50 blkn=1| grep kfbh.block.blk
kfbh.block.blk:                     257 ; 0x004: blk=257

不存在编号为0的ASM文件,所以文件目录的0号block不描述任何文件的信息。

ASM文件目录与ASM的AT表是两个相辅相成的数据结构。ALTER DISKGROUP CHECK命令可以检查两个数据结构是不是一致的。

译者注:通过为ALTER DISKGROUP CHECK语句可以用来校验磁盘组元信息的内部一致性,可以指定在磁盘组、磁盘、文件、failgroup级别进行元信息一致性的校验,能够成功执行此命令的前提条件是磁盘组必须处于mount状态。默认情况下,check disk group 子句会校验所有的元信息目录,在校验过程中如果有错误信息,会记录在ASM的alert文件中,check语句一般会执行如下的操作:1)检查磁盘的一致性 2)检查文件extent map和AT表之间的一致性 3)检查alias元信息目录和文件目录之间对应关系的正确性 4)检查alias目录树的正确性 5) 检查ASM元信息目录是否有不可访问的块。我们可以在语句中添加repair或norepair关键字来指定ASM是否尝试修复检查过程中发生的错误,默认为norepair。

V$ASM_FILE and V$ASM_ALIAS views

ASM文件目录中描述的大部分信息都可以通过V$ASM_FILE视图查询到。对于处于mount状态的磁盘组中的每个文件,该视图中会以一行来展示。然而,该视图中并不会显示ASM元信息文件的信息。V$ASM_FILE视图中没有描述文件名的列,所以为了得到一个有意义的输出,同时我们还需要联合V$ASM_ALIAS视图。

请看如下示例:

SQL> SELECT f.group_number, f.file_number, a.name, f.type
FROM v$asm_file f, v$asm_alias a
WHERE f.group_number=a.group_number and f.file_number=a.file_number
ORDER BY 1, 2;

GROUP_NUMBER FILE_NUMBER NAME                   TYPE
------------ ----------- ---------------------- ----------------
         1         253 REGISTRY.253.769023761 ASMPARAMETERFILE
         1         256 SYSTEM.256.769030243   DATAFILE
         1         257 SYSAUX.257.769030245   DATAFILE
         1         258 UNDOTBS1.258.769030245 DATAFILE
         1         259 USERS.259.769030245    DATAFILE
         1         260 Current.260.769030435  CONTROLFILE
         1         261 Current.261.769030431  CONTROLFILE
         1         262 group_1.262.769030439  ONLINELOG
         1         263 group_1.263.769030445  ONLINELOG
         1         264 group_2.264.769030453  ONLINELOG
         3         256 Current.256.771527253  CONTROLFILE
         3         257 group_1.257.771527259  ONLINELOG
         3         258 group_1.258.771527263  ONLINELOG
...

34 rows selected.

SQL>

不同磁盘组中的文件可以有相同的文件编号。

Locating the ASM file directory

我们可以在ASM实例中通过查询X$KFFXP视图来获取磁盘组DATA中编号为1的文件所分配的AU。

SQL> SELECT xnum_kffxp "Virtual extent",
pxn_kffxp "Physical extent",
au_kffxp "Allocation unit",
disk_kffxp "Disk"
FROM x$kffxp
WHERE group_kffxp=1 -- Diskgroup 1 (DATA)
and number_kffxp=1 -- File 1 (file directory)
ORDER BY 1, 2;

Virtual extent Physical extent Allocation unit       Disk
-------------- --------------- --------------- ----------
           0               0              10          0
           0               1              10          1
           0               2              10          2
           1               3              48          2
           1               4              46          1
           1               5              47          0

6 rows selected.

SQL>

以上结果中我们可以有两个发现:ASM文件目录为三重冗余(每个virtual extent都有3个physical extent);当前ASM文件目录包含两个virtual extent。

当AU大小为1MB且ASM元信息block大小为4KB时,一个AU可以容纳256个目录条目。文件编号1-255是为ASM元信息文件预留,所以0号extent只用来容纳元信息文件的条目,1号extent则容纳接下来的256个非元信息文件的信息,以此类推。

译者注:译者认为这里作者遗漏了一个很重要的定位asm一号文件的方法,通过kfed 读取asm磁盘头的kfdhdb.f1b1locn部分,可以获得ASM一号文件所在的AU,例如下面的例子里显示了一号文件在磁盘的2号AU处,如果kfdhdb.f1b1locn的值为0,代表这个磁盘并没有一号文件的拷贝。

#kfed read /dev/qdata/vdh| grep kfdhdb.f1b1locn
kfdhdb.f1b1locn:                      2 ; 0x0d4: 0x00000002

ASM file directory entries for database files

接下来我们通过以下查询看看哪些文件是被我的ASM实例所管理的。

SQL> SELECT file_number "ASM file number", name "File name"
FROM v$asm_alias
WHERE group_number=1
ORDER BY 1;

ASM file number File name
--------------- ----------------------
          253 REGISTRY.253.769023761
          256 SYSTEM.256.769030243
          257 SYSAUX.257.769030245
          258 UNDOTBS1.258.769030245
          259 USERS.259.769030245
          260 Current.260.769030435
          261 Current.261.769030431
          262 group_1.262.769030439
          263 group_1.263.769030445
          264 group_2.264.769030453
          265 group_2.265.769030461
          266 group_3.266.769030471
          267 group_3.267.769030479
          268 TEMP.268.769030503
          269 EXAMPLE.269.769030517
          270 spfile.270.769030977
...

SQL>

我们看到ASM实例管理着一组典型的数据库文件。接下来再继续深入剖析。

File directory entries for control files

查询该数据库的控制文件名。

SQL> SELECT name "File",
block_size "Block size",
block_size*(file_size_blks+1) "File size"
FROM v$controlfile;

File                                       Block size  File size
------------------------------------------ ---------- ----------
+DATA/BR/CONTROLFILE/current.262.822925011      16384   17973248
+DATA/BR/CONTROLFILE/current.261.822925013      16384   17973248

SQL>

接下来看一下262号文件(current.262.822925011)对应的的文件目录条目。首先,通过查询X$KFFXP获得该文件的extent和AU分布:

SQL> SELECT xnum_kffxp "Virtual extent",
pxn_kffxp "Physical extent",
au_kffxp "Allocation unit",
disk_kffxp "Disk"
FROM x$kffxp
WHERE group_kffxp=1 -- Diskgroup 1 (DATA)
and number_kffxp=262 -- File 262 (control file)
and xnum_kffxp <> 2147483648
ORDER BY 1, 2;

Virtual extent Physical extent Allocation unit Disk
-------------- --------------- --------------- ----
           0               0             776    3
           0               1             778    1
           0               2             779    2
           1               3             781    0
           1               4             777    3
           1               5             779    1
           2               6             780    2
           2               7             780    1
           2               8             778    3
...
          23              69             795    1
          23              70             793    3
          23              71             798    0

72 rows selected.

SQL>

我们看到实例为该文件分配了24个virtual extent,并且该文件是三倍冗余。接下来查询DATA磁盘组包含的磁盘的编号和路径。

SQL> SELECT disk_number, path
FROM v$asm_disk
WHERE group_number=1
ORDER BY 1;

DISK_NUMBER PATH
----------- ---------
        0 /dev/sdb1
        1 /dev/sdc1
        2 /dev/sdd1
        3 /dev/sde1

SQL>

现在我们通过kfed工具来查看该文件的ASM文件目录条目,它会在文件目录的262号block,也就是文件目录中1号extent的6号block(262减去256得出6)。1号extent位于2号磁盘的第48个AU,并在1号磁盘的第46个AU和0号磁盘的第47个AU上分别存在一份冗余。我们只需要看其中一个即可。下面我们来看看2号磁盘的第48个AU。

$ kfed read /dev/sdd1 aun=48 blkn=6 | more
kfbh.endian:                          1 ; 0x000: 0x01
kfbh.hard:                        130 ; 0x001: 0x82
kfbh.type:                            4 ; 0x002: KFBTYP_FILEDIR
kfbh.datfmt:                          1 ; 0x003: 0x01
kfbh.block.blk:                   262 ; 0x004: blk=262
...
kfffdb.node.incarn:         822925011 ; 0x000: A=1 NUMM=0x18866b69
kfffdb.node.frlist.number: 4294967295 ; 0x004: 0xffffffff
kfffdb.node.frlist.incarn:            0 ; 0x008: A=0 NUMM=0x0
kfffdb.hibytes:                       0 ; 0x00c: 0x00000000
kfffdb.lobytes:              17973248 ; 0x010: 0x01124000
kfffdb.xtntcnt:                    72 ; 0x014: 0x00000048
kfffdb.xtnteof:                    72 ; 0x018: 0x00000048
kfffdb.blkSize:                 16384 ; 0x01c: 0x00004000
kfffdb.flags:                      19 ; 0x020: O=1 S=1 S=0 D=0 C=1 I=0 R=0 A=0
kfffdb.fileType:                    1 ; 0x021: 0x01
...
kfffde[0].xptr.au:                776 ; 0x4a0: 0x00000308
kfffde[0].xptr.disk:                3 ; 0x4a4: 0x0003
kfffde[0].xptr.flags:               0 ; 0x4a6: L=0 E=0 D=0 S=0
kfffde[0].xptr.chk:                34 ; 0x4a7: 0x22
kfffde[1].xptr.au:                778 ; 0x4a8: 0x0000030a
kfffde[1].xptr.disk:                1 ; 0x4ac: 0x0001
kfffde[1].xptr.flags:               0 ; 0x4ae: L=0 E=0 D=0 S=0
kfffde[1].xptr.chk:                34 ; 0x4af: 0x22
kfffde[2].xptr.au:                779 ; 0x4b0: 0x0000030b
kfffde[2].xptr.disk:                2 ; 0x4b4: 0x0002
kfffde[2].xptr.flags:               0 ; 0x4b6: L=0 E=0 D=0 S=0
kfffde[2].xptr.chk:                32 ; 0x4b7: 0x20
...

$

通过以上kfed命令输出中的第一部分kfbh字段,我们确认这是一个ASM文件目录的block(kfbh.type=KFBTYP_FILEDIR),而且是描述262号文件的(kfbh.block.blk=262)。

第二部分kfffdb字段则包含:

File incarnation number (kfffdb.node.incarn=822925011), 文件的incarnation号,属于文件名的一部分

File size in bytes (kfffdb.lobytes=17973248) 文件的大小

Physical extent count (kfffdb.xtntcnt=72) 文件的物理extent数

File block size in bytes (kfffdb.blkSize=16384) 文件的块大小

File type (kfffdb.fileType=1), i.e. the database control file 文件的类型,这里为控制文件

第三部分kfffde为物理extent分布,这部分输出与从X$KFFXP中查询到的结果一致:

Physical extent 0 在 AU 776 (kfffde[0].xptr.au=776), 在 disk 3 (kfffde[0].xptr.disk=3) Physical extent 1 在 AU 778 (kfffde[1].xptr.au=778), 在 disk 1 (kfffde[1].xptr.disk=1) Physical extent 2 在 AU 779 (kfffde[2].xptr.au=779), 在 disk 2 (kfffde[2].xptr.disk=2)

以此类推。

File directory entries for large files

本文中所指的大文件指的是超过60个extent的文件。

先到数据库中找出几个大的文件:

SQL> SELECT name, bytes/1024/1024 "Size (MB)"
FROM v$datafile;

NAME                                          Size (MB)
-------------------------------------------- ----------
+DATA/br/datafile/system.256.769030243              720
+DATA/br/datafile/sysaux.257.769030245              590
+DATA/br/datafile/undotbs1.258.769030245            105
+DATA/br/datafile/users.259.769030245                 5
+DATA/br/datafile/example.269.769030517         345.625

SQL>

Directly addressed extents

以system表空间的数据文件为例,我们看一下该文件对应的文件目录条目。该文件编号为256,大小为720MB。

SQL> SELECT xnum_kffxp "Extent", au_kffxp "AU", disk_kffxp "Disk"
FROM x$kffxp
WHERE group_kffxp=1 and number_kffxp=256 and xnum_kffxp <> 2147483648
ORDER BY 1,2;

  Extent         AU       Disk
---------- ---------- ----------
       0         42          1
       0         48          2
       1         43          1
       1         49          0
       2         44          1
       2         45          3
...
     720       1111          1
     720       1119          2

1442 rows selected.

SQL>

我们看到ASM实例为该文件分配了1442个物理extent。

我们再次用kfed工具来查看该文件的文件目录条目。它位于ASM文件目录的256号block,这个块位于48号AU,块0。让我们查看0号disk第48个AU的0号block。

译者注:1号文件的第一个AU保留的是1-255号文件的信息(元信息文件),我们的256号文件,要从1号文件的第二个AU开始算起,由于AU的块编号是从0号块开始,因此256号文件位于第二个AU也就是48号AU的0号块。

0-59号extent(kfffde[0]-kfffde[59])被称作directly addressed extent,因为它们直接指向数据extent。而编号59以上的extent,被称为indirectly addressed extent,因为它们指向的extent持有的是剩余extent的信息。

Indirectly addressed extents

接下来对1号磁盘(kfffde[60].xptr.disk=1)的58号AU(kfffde[60].xptr.au=58)进行查看。

我们看到,这确实是一个indirect extent block(kfbh.type=KFBTYP_INDIRECT),它持有该数据文件剩余的extent的分布信息。

译者注:ASM 10G版本,ASM实例在初始化时,会向数据库实例发送所有数据文件的Extent map,由于这种方式非常影响性能,数据库文件如果很大,需要消耗很多的时间,因此在ASM 11G版本以后,初始化时仅发送Extent map中的前60个Extent(也就是元文件1中记录的60个Extent),其余的在数据库实例有需要时再发送。

Conclusion

ASM文件目录维护了磁盘组中所有文件的相关信息,包括元信息文件、用户创建的文件、数据库文件。我们可以通过查询V$ASM_FILE视图来获取数据库文件的信息。

关于译者

郭旭瑞,沃趣科技产品交付部经理,负责QData Cloud高性能数据库云平台、QBackup数据库秒级备份恢复云平台等产品的整体交付管理与技术支持、维保服务工作。个人网站:www.dbalex.com

原文发布于微信公众号 - 沃趣科技(woqutech)

原文发表时间:2016-07-21

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏张善友的专栏

Ibatis in action 电子书

电子书 ? 是ibatis 项目组写的ibatis开发的权威书籍.现在只有电子版,目前使用Java作为描述的平台,这个书对于.NET和Ruby一样适用.    ...

21970
来自专栏杨建荣的学习笔记

一条关于swap争用的报警邮件分析(一)(r7笔记第28天)

最近这些天有一台服务器总是会收到剩余swap过低的告警。 邮件内容大体如下: ############ ZABBIX-监控系统: --------------...

37940
来自专栏张戈的专栏

常用MySQL语句搜集整理

折腾 WordPress 多少要接触到 MySQL 的一些操作,比如,玛思阁之前重装 postview 插件后发现所有的 view 数据都被清空了!只好到 ph...

40450
来自专栏散尽浮华

mysql操作命令梳理(5)-执行sql语句查询即mysql状态说明

在日常mysql运维中,经常要查询当前mysql下正在执行的sql语句及其他在跑的mysql相关线程,这就用到mysql processlist这个命令了。 m...

26760
来自专栏IT 指南者专栏

【SSH框架】之Hibernate系列(一)

微信公众号:compassblog 欢迎关注、转发,互相学习,共同进步! 有任何问题,请后台留言联系! 1、Hibernate框架概述 (1)、什么是Hiber...

28180
来自专栏c#开发者

分析Oracle数据库日志文件(1)

分析Oracle数据库日志文件(1) 一、如何分析即LogMiner解释 从目前来看,分析Oracle日志的唯一方法就是使用Oracle公司提供的LogMin...

45450
来自专栏魏艾斯博客www.vpsss.net

MySQL 数据库类型从 InnoDB 转换为 MyISAM

19060
来自专栏魏艾斯博客www.vpsss.net

MySQL 数据库类型从 InnoDB 转换为 MyISAM

魏艾斯博客有一个 wordpress 站点,有一天无意中发现数据库挺大的,可是这个站也就不到 10 篇文章,没道理这么大的数据库啊。然后开始查找原因,发现在 p...

526220
来自专栏大数据和云计算技术

MonetDB学习笔记

这个文章是我2013年6月写在博客里面的,翻出来挺有意思,MonetDB有很多技术值得学习。 1 架构: 三层软件架构: SQL front-end:前端SQL...

626110
来自专栏技术翻译

关于Couchbase-Dzone数据库,你必须了解的10件事情

此功能已经存在了一段时间,但仍值得一提。一些Key-Value Store只允许你将整个文档全部整合在一起,这是一个合理的。但是,如果你使用Couchbase作...

28100

扫码关注云+社区

领取腾讯云代金券