Oracle ASM 翻译系列第八弹:ASM Internal ASM file extent map

当ASM创建一个文件时(例如数据库实例要求创建一个数据文件),它会以extent为单位分配空间。一旦文件被创建,ASM会传递extent映射表给数据库实例,后续数据库实例能在不和ASM实例交互的情况下访问这个文件。如果一个文件的extent需要被重新定位,比如磁盘组进行rebalance操作,ASM会告知数据库实例关于extent映射表的变更。

可以通过查询ASM实例的X$KFFXP视图来获取ASM文件extent映射表的内容。X$KFFXP视图中的每一行对应着所有处于mount状态磁盘组中每一个文件的每一个物理extent的信息。

译者注:1)网络上有不少关于X$KFFXP视图的解释,有些信息过于陈旧,需要指出,它记录的每一条记录都代表的是物理extent的信息,而非AU信息,X$KFFXP视图的SIZE_KFFXP字段,代表了此extent是由几个AU组成的,在启用11G可变extent特性后会出现SIZE_KFFXP大于1的情况,具体更多信息参考本系列的第一篇文章。2)X$KFFXP这里翻译成了X$KFFXP视图,只是为了便于理解,它的本质是一个内存的数据结构(fixed table),其数据不在buffer_cache中。

X$KFFXP视图的重要字段包括:

GROUP_KFFXP 磁盘组编号。注意磁盘组编号不是恒久不变的,每次磁盘组被mount时都可能会不一样。等同于V$ASM_DISKGROUP.GROUP_NUMBER字段。

NUMBER_KFFXP 文件序号。等同于 V$ASM_FILE.FILE_NUMBER字段。 注意,ASM的文件序号不同于数据库内的数据文件序号,不要把两个概念搞混了。小于256的ASM文件序号是保留给ASM元数据文件使用的。

INCARN_KFFXP 文件版本号。当一个ASM文件序号被一个新文件重用时,文件版本号会发生改变。等同于V$ASM_FILE.INCARNATION字段。注意,ASM文件是以文件序号.版本号的方式结尾。

XNUM_KFFXP 虚拟extent序号。external冗余磁盘组的虚拟extent序号与物理extent序号一致。 normal冗余磁盘组的虚拟extent序号通过将物理extent序号除于2得到.high冗余磁盘组的虚拟extent序号通过将物理extent序号除于3得到.

PXN_KFFXP 物理extent序号。一个文件的物理extent序号都以数字0开始,顺序递增。

LXN_KFFXP 虚拟extent中物理extent的序号。 0 为 primary extent, 1 为 secondary extent, 2 为 third copy of the extent。

DISK_KFFXP 物理磁盘序号。等同于V$ASM_DISK.DISK_NUMBER。

AU_KFFXP AU序号,磁盘维度的AU编号,每个磁盘从0开始。

在ASM实例中通过以下查询,能够看出磁盘组3内的ASM元数据文件的文件序号,名字和AU数量。

$ sqlplus / as sysasm

SQL> select NUMBER_KFFXP "ASM file number", DECODE (NUMBER_KFFXP,

1, 'File directory', 2, 'Disk directory', 3, 'Active change directory', 4, 'Continuing operations directory',

5, 'Template directory', 6, 'Alias directory', 7, 'ADVM file directory', 8, 'Disk free space directory',

9, 'Attributes directory', 10, 'ASM User directory', 11, 'ASM user group directory', 12, 'Staleness directory',

253, 'spfile for ASM instance', 254, 'Stale bit map space registry ', 255, 'Oracle Cluster Repository registry') "ASM metadata file name",

count(AU_KFFXP) "Allocation units"

from X$KFFXP

where GROUP_KFFXP=3 and NUMBER_KFFXP<256

group by NUMBER_KFFXP

order by 1;

ASM file number ASM metadata file name             Allocation units

--------------- ---------------------------------- ----------------

1 File directory                                    3

2 Disk directory                                    3

3 Active change directory                          69

4 Continuing operations directory                   6

5 Template directory                                3

6 Alias directory                                   3

8 Disk free space directory                         3

9 Attributes directory                              3

12 Staleness directory                               3

253 spfile for ASM instance                           2

254 Stale bit map space registry                      3

255 Oracle Cluster Repository registry              135

12 rows selected.

SQL>

通过以上查询结果可以发现,这个磁盘组并没有包含所有类型的元数据文件(例如第十号和第十一号文件)。一个有意思的事情是,除了ASM实例的spfile,每个文件至少占用3个AU,对于这一点更多详细信息我们会在其他章节介绍。

我们再来以一个数据库控制文件为例查看下它的extent映射表

第1步,查找DATA磁盘组内所有的数据库控制文件(以Grid所属的OS用户身份运行asmcmd命令)

$ asmcmd find --type controlfile +DATA "*"

+DATA/DBM/CONTROLFILE/Current.256.738247649

+DATA/BR/CONTROLFILE/Current.299.748434267

$

第2步,检查DATA磁盘组的磁盘组序号(连接到asm实例)

$ sqlplus / as sysasm

SQL> select GROUP_NUMBER from V$ASM_DISKGROUP where NAME='DATA';

GROUP_NUMBER

------------

1

SQL>

第3步,检查磁盘组1中ASM 256号文件(+DATA/DBM/CONTROLFILE/Current.256.738247649)的extent映射表

SQL> select XNUM_KFFXP "Virtual extent", PXN_KFFXP "Physical extent", LXN_KFFXP "Extent copy", DISK_KFFXP "Disk", AU_KFFXP "Allocation unit"

from X$KFFXP

where GROUP_KFFXP=1 and NUMBER_KFFXP=256 and XNUM_KFFXP<>2147483648

order by 1,2;

Virtual extent Physical extent Extent copy       Disk Allocation unit

-------------- --------------- ----------- ---------- ---------------

0               0           0         20               5

0               1           1         29            1903

0               2           2          6              82

1               3           0         22               6

1               4           1         31               8

1               5           2          9               3

2               6           0         30               8

2               7           1         23            1907

2               8           2          7              63

3               9           0         26               2

3              10           1         16            1904

3              11           2          6               4

...

39             117           0         25            1913

39             118           1         15            1906

39             119           2          3              27

120 rows selected.

SQL>

以上输出可以看出这个控制文件是三路镜像,每个虚拟extent对应三个物理extent,还可以看出这个文件每个AU的实际位置。

时间: 2024-09-28 23:01:43

Oracle ASM 翻译系列第八弹:ASM Internal ASM file extent map的相关文章

Oracle ASM 翻译系列第十弹:ASM Internal ASM DISK header

ASM disk header ASM磁盘头可能是ASM元数据中最广为人知的部分.之前你可能认为当它被破坏或丢失时,只能寄希望于Oracle技术支持人员协助来恢复.在本节中将解释ASM磁盘头的重要性和它包含的信息. Block zero ASM磁盘是以AU为单位进行格式化的,部分AU会存放ASM元数据,其他AU存放数据库中的相关数据(如数据文件.备份文件.归档文件等等).包含ASM元数据的AU会以元数据块的方式进行格式化(一个元数据块的大小为4K).AU0位于ASM磁盘的起始位置,它始终用于存储

Oracle ASM 翻译系列第二十一弹:ASM Attributes Directory

ASM Attributes Directory ASM的元数据9号文件,是ASM属性目录,包含了磁盘组的属性信息.属性目录只有在磁盘组的compatible.asm属性设置为11.1或以上时才会存在. 直到ASM 11.1版本开始,才引入了磁盘组属性的概念,它被用来细粒度的调整磁盘组的属性.有些属性只能在磁盘组创建时指定(如au_size),有些属性可以在任何时候指定(如disk_repair_time).有些属性保存在磁盘头中(如au_size),有些属性被存储在[成员关系和状态表]中或磁盘

Oracle ASM 翻译系列第十一弹:高级知识 Offline or drop?

Offline or drop? 当一个ASM磁盘不可用时,ASM会把它从磁盘组里移除,对吗?要看情况,通常取决于ASM版本和磁盘组的冗余级别.因为一个external冗余的磁盘组会直接被dismount,所以主要关注normal和high冗余磁盘组的情况. ASM 10g版本,磁盘会被直接drop.从11gR1,一个磁盘不可用时会先被offline,此时disk repair计时器开始介入,如果计时器达到磁盘组DISK_REPAIR_TIME 属性值时,这个磁盘会从所属的磁盘组中drop掉.如

Oracle ASM 翻译系列第二十弹:ASM Internal ASM file number 7

ASM file number 7 ASM元信息7号文件,是ASM的逻辑卷目录,用于跟踪与ADVM有关的文件. ASM动态逻辑卷设备是由ASM动态逻辑卷构建的.一个磁盘组中可以配置一个或多个ASM动态逻辑卷设备.ASM集群文件系统通过ADVM接口构建在ASM磁盘组之上.ADVM像数据库一样,也是ASM的一个客户端.当一个逻辑卷被访问时,相应的ASM文件会被打开并且ASM extent的信息会被发送到ADVM驱动. 有两种与ADVM逻辑卷相关的文件类型: · ASMVOL:逻辑卷文件,作为逻辑卷存

Oracle ASM 翻译系列第十七弹:ASM Internal ASM Disk Directory

ASM Disk Directory 本篇文章讲述ASM元信息的2号文件,ASM的2号文件是ASM的磁盘目录,它跟踪磁盘组中的所有磁盘.由于在ASM中磁盘组是一个独立的存储单位,因此每一个磁盘组都会有自己的磁盘目录. 译者注:ASM中每一个磁盘组都是自解释的,磁盘组之间没有任何的信息上依赖 对ASM来说,磁盘目录只是一个普通的ASM文件,在ASM的文件目录中也会有它的条目,如果磁盘组做了冗余策略,它也会相应做镜像,也会像其他文件一样根据实际需要做空间的伸长. 每个磁盘目录的条目都维护了如下的一些

ASM 翻译系列第三弹:基础知识 About ASM disk groups, disks and files

Oracle ASM使用磁盘组来存放数据文件,每一个ASM的磁盘组由一些ASM磁盘组成,每一个ASM磁盘组本身是一个独立的存储单元,是自描述的,对于ASM磁盘组中数据库文件,ASM提供一个文件系统的接口,方便DBA做管理.存放在ASM磁盘组中的文件被均匀的分布在磁盘组中的所有磁盘上,通过这种方式,每一块磁盘都可以提供一致的性能,同时ASM的性能可以比得上裸设备的性能.[摘录自11GR2版本的ASM官方文档] ASM Disk Groups 一个ASM磁盘组是由一个或多个ASM磁盘组成的,每个AS

ASM 翻译系列第四弹:高级知识 kfed 元数据编辑器

kfed - ASM metadata editor kfed是一个没有官方文档记录的ASM工具,它可以用来读取和修改ASM的元数据块.它本身是一个独立的工具,独立于ASM实例,因此不管实例是否启动,ASM磁盘组是否mount ,它都可以正常使用.kfed最为强大的地方在于它可以修复ASM损坏的元数据. kfed的二进制文件在最近的ASM版本中直接可用,如果你没有在$ORACLE_HOME/bin看到,可以通过如下步骤来编译获得: $ cd $ORACLE_HOME/rdbms/lib $ ma

Oracle ASM 翻译系列第二十七弹:ASM INTERNAL ASM METADATA BLOCK

ASM METADATA BLOCK ASM的元数据由ASM实例进行维护和管理,元信息本身非常重要,ASM磁盘组中的文件要想被Oracle DB和其他客户端正常使用,就要求元信息一定要是完好无损的,ASM的元信息以元信息块的形式存储在磁盘组中. 译者注:ASM的元信息可以类比为Oracle数据库的数据字典,一旦核心的元信息发生毁坏,那么ASM磁盘组将不能被装载继而提供服务. 有些ASM 元数据在每个ASM 磁盘的固定位置,被称为物理元信息,有些ASM元数据是以文件(目录)形式保存,被称为虚拟元数

Oracle ASM 翻译系列第六弹:高级知识 如何映射asmlib管理的盘到它对应的设备名

当使用ASMLIB 来管理ASM 磁盘时,设备的路径信息是不会在gv$asm_disk视图path列中显示的,如果你使用的是ASMLIB Support Tools 2.1 或者更高(oracleasm-support-2.1*的rpm包)版本,可以通过root用户运行'oracleasm querydisk -p'来获得设备路径信息: # ls -l /dev/oracleasm/disks total 0 brw-rw---- 1 grid asmadmin 8,  5 May  2 12: