ASM元信息的10号文件是ASM用户目录，11号文件是组目录。它们是用来为ASM文件访问控制特性提供支持的元信息结构。ASM文件访问控制机制用来限制特定的ASM客户端(通常就是数据库实例)对文件的访问，它是基于操作系统层database home的effective user标识号实现的。这些信息可以通过V$ASM_USER、V$ASM_USERGROUP、$ASM_USERGROUP_MEMBER视图查询到。
ASM用户与组
如果要使用ASM文件访问控制特性，我们需要适当的设置操作系统用户和组。通过ALTER DISKGROUP ADD USERGROUP命令将用户和组添加至ASM磁盘组中。下面的语句将对5号磁盘组(USD)增加用户组。
下面是操作系统中我们创建的用户。
[root@jyrac1 bin]# id grid uid=500(grid) gid=505(oinstall) groups=505(oinstall),500(asmadmin),501(asmdba),502(asmoper),503(dba) [root@jyrac1 bin]# id oracle uid=501(oracle) gid=505(oinstall) groups=505(oinstall),501(asmdba),503(dba),504(oper)
给磁盘组设置用户与组
SQL> alter diskgroup usd add usergroup 'test_usergroup' with member 'grid','oracle'; alter diskgroup usd add usergroup 'test_usergroup' with member 'grid','oracle' * ERROR at line 1: ORA-15032: not all alterations performed ORA-15304: operation requires ACCESS_CONTROL.ENABLED attribute to be TRUE
错误信息显示对于5号磁盘组(USD)的access_control.enabled属性需要启用才能给磁盘组设置用户与组
[grid@jyrac1 ~]$ asmcmd setattr -G USD access_control.enabled 'TRUE'; [grid@jyrac1 ~]$ asmcmd lsattr -lm access_control.enabled Group_Name Name Value RO Sys ACFS access_control.enabled FALSE N Y ARCHDG access_control.enabled FALSE N Y CRSDG access_control.enabled FALSE N Y DATADG access_control.enabled FALSE N Y USD access_control.enabled TRUE N Y SQL> alter diskgroup usd add usergroup 'test_usergroup' with member 'grid','oracle'; Diskgroup altered.
执行以下查询来获得在磁盘组中设置的用户和组
SQL> col "disk group#" for 999
SQL> col "os id" for a10
SQL> col "os user" for a10
SQL> col "asm user#" for 999
SQL> col "asm group#" for 999
SQL> col "asm user group" for a40
SQL> select u.group_number "disk group#",
2 u.os_id "os id",
3 u.os_name "os user",
4 u.user_number "asm user#",
5 g.usergroup_number "asm group#",
6 g.name "asm user group"
7 from v$asm_user u, v$asm_usergroup g, v$asm_usergroup_member m
8 where u.group_number=g.group_number and u.group_number=m.group_number
9 and u.user_number=m.member_number
10 and g.usergroup_number=m.usergroup_number
11 order by 1, 2;
disk group# os id os user asm user# asm group# asm user group
----------- ---------- ---------- --------- ---------- ----------------------------------------
5 500 grid 1 1 test_usergroup
5 501 oracle 2 1 test_usergroup
获取5号磁盘组的ASM用户和组目录所在的AU
SQL> select x.number_kffxp "file#",x.group_kffxp "group#",x.disk_kffxp "disk #",d.name "disk name",d.path "disk path",x.xnum_kffxp "virtual extent",pxn_kffxp "physical extent",x.au_kffxp "au" 2 from x$kffxp x, v$asm_disk_stat d 3 where x.group_kffxp=d.group_number 4 and x.disk_kffxp=d.disk_number 5 and x.group_kffxp=5 6 and x.number_kffxp in(10,11) 7 order by 1,2,3; file# group# disk # disk name disk path virtual extent physical extent au ----- ---------- ---------- ------------------------------ ---------------------------------------- -------------- --------------- ---------- 10 5 0 USD_0000 /dev/raw/raw7 0 1 100 10 5 1 USD_0001 /dev/raw/raw12 0 0 164 11 5 0 USD_0000 /dev/raw/raw7 0 1 101 11 5 1 USD_0001 /dev/raw/raw12 0 0 165
从上面的结果可以看到10号文件有两份镜像，分别存储在5号磁盘组的0号磁盘(/dev/raw/raw7)的100号AU与1号磁盘(/dev/raw/raw12)的164号AU，11号文件有两份镜像分别存储在分别存储在5号磁盘组的0号磁盘(/dev/raw/raw7)的101号AU与1号磁盘(/dev/raw/raw12)的165号AU。
通过kfed工具来获得5号磁盘组的用户与组目录的AU分布情况
由于1号文件总是开始在0号磁盘2号AU，记住这个位置：0号盘2号AU。这是ASM中定位文件的起点，它的作用，有点相当于磁盘上的引导区，在电脑开机后负责将OS启动起来。1号文件在最少情况下，至少有两个AU。在1号文件中，每个文件占用一个元数据块，存放自身的空间分布信息。每个元数据块大小是4K，一个AU是1M，哪么，每个AU中，可以存储256个文件的空间分布信息。这其中，0号盘2号AU中，全是元文件的信息。再具体一点，0号盘2号AU，第一个元数据块被系统占用，从第二个块开始，到255为止，共255个元数据块，对应索引号1至255的文件。其实，也就是全部的元文件了。也就是说0号盘2号AU，保存了全部元文件的空间分布信息。1号文件的第二个AU，从第一个块开始，保存256号文件。第二个块对应257号文件，等等。每次从ASM中读数据时，Oracle都要先读到1号文件，从中找出要读的目标文件在磁盘上的分布位置，然后再去读取相应的文件的数据。由于用户目录是10号文件，组目录是11号文件，这可以通过读取5号磁盘组的0号磁盘(/dev/raw/raw7)的2号AU的10与11号块来获得
[grid@jyrac1 ~]$ kfed read /dev/raw/raw7 aun=2 blkn=10 | 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: 10 ; 0x004: blk=10 kfbh.block.obj: 1 ; 0x008: file=1 kfbh.check: 751075078 ; 0x00c: 0x2cc47f06 kfbh.fcn.base: 7473 ; 0x010: 0x00001d31 kfbh.fcn.wrap: 0 ; 0x014: 0x00000000 kfbh.spare1: 0 ; 0x018: 0x00000000 kfbh.spare2: 0 ; 0x01c: 0x00000000 kfffdb.node.incarn: 1 ; 0x000: A=1 NUMM=0x0 kfffdb.node.frlist.number: 4294967295 ; 0x004: 0xffffffff kfffdb.node.frlist.incarn: 0 ; 0x008: A=0 NUMM=0x0 kfffdb.hibytes: 0 ; 0x00c: 0x00000000 kfffdb.lobytes: 1048576 ; 0x010: 0x00100000 kfffdb.xtntcnt: 3 ; 0x014: 0x00000003 kfffdb.xtnteof: 3 ; 0x018: 0x00000003 kfffdb.blkSize: 4096 ; 0x01c: 0x00001000 kfffdb.flags: 1 ; 0x020: O=1 S=0 S=0 D=0 C=0 I=0 R=0 A=0 kfffdb.fileType: 15 ; 0x021: 0x0f kfffdb.dXrs: 19 ; 0x022: SCHE=0x1 NUMB=0x3 kfffdb.iXrs: 19 ; 0x023: SCHE=0x1 NUMB=0x3 kfffdb.dXsiz[0]: 4294967295 ; 0x024: 0xffffffff kfffdb.dXsiz[1]: 0 ; 0x028: 0x00000000 kfffdb.dXsiz[2]: 0 ; 0x02c: 0x00000000 kfffdb.iXsiz[0]: 4294967295 ; 0x030: 0xffffffff kfffdb.iXsiz[1]: 0 ; 0x034: 0x00000000 kfffdb.iXsiz[2]: 0 ; 0x038: 0x00000000 kfffdb.xtntblk: 3 ; 0x03c: 0x0003 kfffdb.break: 60 ; 0x03e: 0x003c kfffdb.priZn: 0 ; 0x040: KFDZN_COLD kfffdb.secZn: 0 ; 0x041: KFDZN_COLD kfffdb.ub2spare: 0 ; 0x042: 0x0000 kfffdb.alias[0]: 4294967295 ; 0x044: 0xffffffff kfffdb.alias[1]: 4294967295 ; 0x048: 0xffffffff kfffdb.strpwdth: 0 ; 0x04c: 0x00 kfffdb.strpsz: 0 ; 0x04d: 0x00 kfffdb.usmsz: 0 ; 0x04e: 0x0000 kfffdb.crets.hi: 33043408 ; 0x050: HOUR=0x10 DAYS=0x1e MNTH=0xc YEAR=0x7e0 kfffdb.crets.lo: 2908193792 ; 0x054: USEC=0x0 MSEC=0x1e1 SECS=0x15 MINS=0x2b kfffdb.modts.hi: 33043408 ; 0x058: HOUR=0x10 DAYS=0x1e MNTH=0xc YEAR=0x7e0 kfffdb.modts.lo: 2908193792 ; 0x05c: USEC=0x0 MSEC=0x1e1 SECS=0x15 MINS=0x2b kfffdb.dasz[0]: 0 ; 0x060: 0x00 kfffdb.dasz[1]: 0 ; 0x061: 0x00 kfffdb.dasz[2]: 0 ; 0x062: 0x00 kfffdb.dasz[3]: 0 ; 0x063: 0x00 kfffdb.permissn: 0 ; 0x064: 0x00 kfffdb.ub1spar1: 0 ; 0x065: 0x00 kfffdb.ub2spar2: 0 ; 0x066: 0x0000 kfffdb.user.entnum: 0 ; 0x068: 0x0000 kfffdb.user.entinc: 0 ; 0x06a: 0x0000 kfffdb.group.entnum: 0 ; 0x06c: 0x0000 kfffdb.group.entinc: 0 ; 0x06e: 0x0000 kfffdb.spare[0]: 0 ; 0x070: 0x00000000 kfffdb.spare[1]: 0 ; 0x074: 0x00000000 kfffdb.spare[2]: 0 ; 0x078: 0x00000000 kfffdb.spare[3]: 0 ; 0x07c: 0x00000000 kfffdb.spare[4]: 0 ; 0x080: 0x00000000 kfffdb.spare[5]: 0 ; 0x084: 0x00000000 kfffdb.spare[6]: 0 ; 0x088: 0x00000000 kfffdb.spare[7]: 0 ; 0x08c: 0x00000000 kfffdb.spare[8]: 0 ; 0x090: 0x00000000 kfffdb.spare[9]: 0 ; 0x094: 0x00000000 kfffdb.spare[10]: 0 ; 0x098: 0x00000000 kfffdb.spare[11]: 0 ; 0x09c: 0x00000000 kfffdb.usm: ; 0x0a0: length=0 kfffde[0].xptr.au: 164 ; 0x4a0: 0x000000a4 kfffde[0].xptr.disk: 1 ; 0x4a4: 0x0001 kfffde[0].xptr.flags: 0 ; 0x4a6: L=0 E=0 D=0 S=0 kfffde[0].xptr.chk: 143 ; 0x4a7: 0x8f kfffde[1].xptr.au: 100 ; 0x4a8: 0x00000064 kfffde[1].xptr.disk: 0 ; 0x4ac: 0x0000 kfffde[1].xptr.flags: 0 ; 0x4ae: L=0 E=0 D=0 S=0 kfffde[1].xptr.chk: 78 ; 0x4af: 0x4e kfffde[2].xptr.au: 4294967294 ; 0x4b0: 0xfffffffe kfffde[2].xptr.disk: 65534 ; 0x4b4: 0xfffe kfffde[2].xptr.flags: 0 ; 0x4b6: L=0 E=0 D=0 S=0 kfffde[2].xptr.chk: 42 ; 0x4b7: 0x2a
从上面的kfffde[0].xptr.au=164,kfffde[0].xptr.disk=1与kfffde[1].xptr.au=100,kfffde[1].xptr.disk=0可知10号文件有两份镜像，分别存储在5号磁盘组的0号磁盘(/dev/raw/raw7)的100号AU与1号磁盘(/dev/raw/raw12)的164号AU,与查询语句所获得的结果完全一致。
[grid@jyrac1 ~]$ kfed read /dev/raw/raw7 aun=2 blkn=11 | 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: 11 ; 0x004: blk=11 kfbh.block.obj: 1 ; 0x008: file=1 kfbh.check: 751074319 ; 0x00c: 0x2cc47c0f kfbh.fcn.base: 7737 ; 0x010: 0x00001e39 kfbh.fcn.wrap: 0 ; 0x014: 0x00000000 kfbh.spare1: 0 ; 0x018: 0x00000000 kfbh.spare2: 0 ; 0x01c: 0x00000000 kfffdb.node.incarn: 1 ; 0x000: A=1 NUMM=0x0 kfffdb.node.frlist.number: 4294967295 ; 0x004: 0xffffffff kfffdb.node.frlist.incarn: 0 ; 0x008: A=0 NUMM=0x0 kfffdb.hibytes: 0 ; 0x00c: 0x00000000 kfffdb.lobytes: 1048576 ; 0x010: 0x00100000 kfffdb.xtntcnt: 3 ; 0x014: 0x00000003 kfffdb.xtnteof: 3 ; 0x018: 0x00000003 kfffdb.blkSize: 4096 ; 0x01c: 0x00001000 kfffdb.flags: 1 ; 0x020: O=1 S=0 S=0 D=0 C=0 I=0 R=0 A=0 kfffdb.fileType: 15 ; 0x021: 0x0f kfffdb.dXrs: 19 ; 0x022: SCHE=0x1 NUMB=0x3 kfffdb.iXrs: 19 ; 0x023: SCHE=0x1 NUMB=0x3 kfffdb.dXsiz[0]: 4294967295 ; 0x024: 0xffffffff kfffdb.dXsiz[1]: 0 ; 0x028: 0x00000000 kfffdb.dXsiz[2]: 0 ; 0x02c: 0x00000000 kfffdb.iXsiz[0]: 4294967295 ; 0x030: 0xffffffff kfffdb.iXsiz[1]: 0 ; 0x034: 0x00000000 kfffdb.iXsiz[2]: 0 ; 0x038: 0x00000000 kfffdb.xtntblk: 3 ; 0x03c: 0x0003 kfffdb.break: 60 ; 0x03e: 0x003c kfffdb.priZn: 0 ; 0x040: KFDZN_COLD kfffdb.secZn: 0 ; 0x041: KFDZN_COLD kfffdb.ub2spare: 0 ; 0x042: 0x0000 kfffdb.alias[0]: 4294967295 ; 0x044: 0xffffffff kfffdb.alias[1]: 4294967295 ; 0x048: 0xffffffff kfffdb.strpwdth: 0 ; 0x04c: 0x00 kfffdb.strpsz: 0 ; 0x04d: 0x00 kfffdb.usmsz: 0 ; 0x04e: 0x0000 kfffdb.crets.hi: 33043408 ; 0x050: HOUR=0x10 DAYS=0x1e MNTH=0xc YEAR=0x7e0 kfffdb.crets.lo: 2908340224 ; 0x054: USEC=0x0 MSEC=0x270 SECS=0x15 MINS=0x2b kfffdb.modts.hi: 33043408 ; 0x058: HOUR=0x10 DAYS=0x1e MNTH=0xc YEAR=0x7e0 kfffdb.modts.lo: 2908340224 ; 0x05c: USEC=0x0 MSEC=0x270 SECS=0x15 MINS=0x2b kfffdb.dasz[0]: 0 ; 0x060: 0x00 kfffdb.dasz[1]: 0 ; 0x061: 0x00 kfffdb.dasz[2]: 0 ; 0x062: 0x00 kfffdb.dasz[3]: 0 ; 0x063: 0x00 kfffdb.permissn: 0 ; 0x064: 0x00 kfffdb.ub1spar1: 0 ; 0x065: 0x00 kfffdb.ub2spar2: 0 ; 0x066: 0x0000 kfffdb.user.entnum: 0 ; 0x068: 0x0000 kfffdb.user.entinc: 0 ; 0x06a: 0x0000 kfffdb.group.entnum: 0 ; 0x06c: 0x0000 kfffdb.group.entinc: 0 ; 0x06e: 0x0000 kfffdb.spare[0]: 0 ; 0x070: 0x00000000 kfffdb.spare[1]: 0 ; 0x074: 0x00000000 kfffdb.spare[2]: 0 ; 0x078: 0x00000000 kfffdb.spare[3]: 0 ; 0x07c: 0x00000000 kfffdb.spare[4]: 0 ; 0x080: 0x00000000 kfffdb.spare[5]: 0 ; 0x084: 0x00000000 kfffdb.spare[6]: 0 ; 0x088: 0x00000000 kfffdb.spare[7]: 0 ; 0x08c: 0x00000000 kfffdb.spare[8]: 0 ; 0x090: 0x00000000 kfffdb.spare[9]: 0 ; 0x094: 0x00000000 kfffdb.spare[10]: 0 ; 0x098: 0x00000000 kfffdb.spare[11]: 0 ; 0x09c: 0x00000000 kfffdb.usm: ; 0x0a0: length=0 kfffde[0].xptr.au: 165 ; 0x4a0: 0x000000a5 kfffde[0].xptr.disk: 1 ; 0x4a4: 0x0001 kfffde[0].xptr.flags: 0 ; 0x4a6: L=0 E=0 D=0 S=0 kfffde[0].xptr.chk: 142 ; 0x4a7: 0x8e kfffde[1].xptr.au: 101 ; 0x4a8: 0x00000065 kfffde[1].xptr.disk: 0 ; 0x4ac: 0x0000 kfffde[1].xptr.flags: 0 ; 0x4ae: L=0 E=0 D=0 S=0 kfffde[1].xptr.chk: 79 ; 0x4af: 0x4f kfffde[2].xptr.au: 4294967294 ; 0x4b0: 0xfffffffe kfffde[2].xptr.disk: 65534 ; 0x4b4: 0xfffe kfffde[2].xptr.flags: 0 ; 0x4b6: L=0 E=0 D=0 S=0 kfffde[2].xptr.chk: 42 ; 0x4b7: 0x2a
从上面的kfffde[0].xptr.au=165,kfffde[0].xptr.disk=1与kfffde[1].xptr.au=101,kfffde[1].xptr.disk=0可知11号文件有两份镜像，分别存储在5号磁盘组的0号磁盘(/dev/raw/raw7)的101号AU与1号磁盘(/dev/raw/raw12)的165号AU,与查询语句所获得的结果完全一致。
对于每个用户，用户目录元信息中都有一个block相对应，而block号是跟用户号(对应v$asm_user的user_number列)相对应的。我们有两个用户，用户号码分别对应1-2，那么他们也分别位于1-2号block中。接下来加以验证。
[grid@jyrac1 ~]$ kfed read /dev/raw/raw7 aun=100 blkn=1 | more kfbh.endian: 1 ; 0x000: 0x01 kfbh.hard: 130 ; 0x001: 0x82 kfbh.type: 24 ; 0x002: KFBTYP_USERDIR kfbh.datfmt: 1 ; 0x003: 0x01 kfbh.block.blk: 1 ; 0x004: blk=1 kfbh.block.obj: 10 ; 0x008: file=10 kfbh.check: 4275524483 ; 0x00c: 0xfed75383 kfbh.fcn.base: 7745 ; 0x010: 0x00001e41 kfbh.fcn.wrap: 0 ; 0x014: 0x00000000 kfbh.spare1: 0 ; 0x018: 0x00000000 kfbh.spare2: 0 ; 0x01c: 0x00000000 kffdnd.bnode.incarn: 1 ; 0x000: A=1 NUMM=0x0 kffdnd.bnode.frlist.number: 4294967295 ; 0x004: 0xffffffff kffdnd.bnode.frlist.incarn: 0 ; 0x008: A=0 NUMM=0x0 kffdnd.overfl.number: 2 ; 0x00c: 0x00000002 kffdnd.overfl.incarn: 1 ; 0x010: A=1 NUMM=0x0 kffdnd.parent.number: 4294967295 ; 0x014: 0xffffffff kffdnd.parent.incarn: 0 ; 0x018: A=0 NUMM=0x0 kffdnd.fstblk.number: 0 ; 0x01c: 0x00000000 kffdnd.fstblk.incarn: 1 ; 0x020: A=1 NUMM=0x0 kfzude.entry.incarn: 1 ; 0x024: A=1 NUMM=0x0 kfzude.entry.hash: 0 ; 0x028: 0x00000000 kfzude.entry.refer.number: 4294967295 ; 0x02c: 0xffffffff kfzude.entry.refer.incarn: 0 ; 0x030: A=0 NUMM=0x0 kfzude.flags: 0 ; 0x034: 0x00000000 kfzude.user: 500 ; 0x038: length=3 ...
1号block对应500号操作系统用户。这与上文v$asm_user查询结果是匹配的。接下来看其他block。
[grid@jyrac1 ~]$ vi getuser.sh let b=1 while (($b < = 2)) do kfed read /dev/raw/raw7 aun=100 blkn=$b | grep kfzude.user let b=b+1 done [grid@jyrac1 ~]$ chmod 777 getuser.sh [grid@jyrac1 ~]$ ./getuser.sh kfzude.user: 500 ; 0x038: length=3 kfzude.user: 501 ; 0x038: length=3
正如所想的，以上显示了ASM用户目录中的两个操作系统用户对应的ID。
组目录也是一个条目对应一个block，block号也是跟ASM组号码匹配的，继续验证。
[grid@jyrac1 ~]$ kfed read /dev/raw/raw7 aun=101 blkn=1 | more kfbh.endian: 1 ; 0x000: 0x01 kfbh.hard: 130 ; 0x001: 0x82 kfbh.type: 25 ; 0x002: KFBTYP_GROUPDIR kfbh.datfmt: 1 ; 0x003: 0x01 kfbh.block.blk: 1 ; 0x004: blk=1 kfbh.block.obj: 11 ; 0x008: file=11 kfbh.check: 2137693031 ; 0x00c: 0x7f6a9b67 kfbh.fcn.base: 7747 ; 0x010: 0x00001e43 kfbh.fcn.wrap: 0 ; 0x014: 0x00000000 kfbh.spare1: 0 ; 0x018: 0x00000000 kfbh.spare2: 0 ; 0x01c: 0x00000000 kffdnd.bnode.incarn: 1 ; 0x000: A=1 NUMM=0x0 kffdnd.bnode.frlist.number: 4294967295 ; 0x004: 0xffffffff kffdnd.bnode.frlist.incarn: 0 ; 0x008: A=0 NUMM=0x0 kffdnd.overfl.number: 4294967295 ; 0x00c: 0xffffffff kffdnd.overfl.incarn: 0 ; 0x010: A=0 NUMM=0x0 kffdnd.parent.number: 4294967295 ; 0x014: 0xffffffff kffdnd.parent.incarn: 0 ; 0x018: A=0 NUMM=0x0 kffdnd.fstblk.number: 0 ; 0x01c: 0x00000000 kffdnd.fstblk.incarn: 1 ; 0x020: A=1 NUMM=0x0 kfzgde.entry.incarn: 1 ; 0x024: A=1 NUMM=0x0 kfzgde.entry.hash: 0 ; 0x028: 0x00000000 kfzgde.entry.refer.number: 4294967295 ; 0x02c: 0xffffffff kfzgde.entry.refer.incarn: 0 ; 0x030: A=0 NUMM=0x0 kfzgde.flags: 0 ; 0x034: 0x00000000 kfzgde.owner.entnum: 1 ; 0x038: 0x0001 kfzgde.owner.entinc: 1 ; 0x03a: 0x0001 kfzgde.name: test_usergroup ; 0x03c: length=14 ...
组目录也是一个条目对应一个block，block号也是跟ASM组号码匹配的，因为我这里只有一个用户组，如果有多个可以编写脚本来进行获得
[grid@jyrac1 ~]$ vi getusergroup.sh let b=1 while (($b < = 3)) do kfed read /dev/raw/raw7 aun=101 blkn=$b | grep kfzgde.name let b=b+1 done [grid@jyrac1 ~]$ chmod 777 getusergroup.sh [grid@jyrac1 ~]$ ./getusergroup.sh kfzgde.name: test_usergroup ; 0x03c: length=14 kfzgde.name: ; 0x03c: length=0 kfzgde.name: ; 0x03c: length=0
小结:
ASM用户目录和组目录是用来为ASM文件访问控制特性提供支持的元信息结构，该特性在11.2版本中引入。这些信息可以通过V$ASM_USER、V$ASM_USERGROUP、$ASM_USERGROUP_MEMBER视图查询到。