原作者:Bane Radulovic
译者: 魏兴华
审核: 魏兴华
DBGeeK联合出品
原文链接:http://asmsupportguy.blogspot.sg/2014/02/acfs-disk-group-rebalance.html
从Oracle 11.2版本开始,可以在ASM磁盘组之上创建通用的集群文件系统,被称为Oracle ASM Cluster File Systems或Oracle ACFS。要想创建一个ACFS文件系统,首先需要在ASM磁盘组之上创建特定的卷,这个卷在OS上是一个块设备,ACFS文件系统就创建于这些块设备之上。
本篇文章主要是关于对ACFS卷文件的重平衡、镜像和区管理的介绍。
首先说明一下测试使用的环境信息:
64-bit Oracle Linux 5.4, in Oracle Virtual Box
Oracle Restart and ASM version 11.2.0.3.0 - 64bit
ASMLib/oracleasm version 2.1.7 Set up ACFS volumes
Set up ACFS volumes
由于我的环境使用的是单实例的Oracle Restart ,因此我需要手工来load ADVM/ACFS 的驱动。(在RAC环境下是自动load的,不需要手工干预)。
64-bit Oracle Linux 5.4, in Oracle Virtual Box
# acfsload start
ACFS-9391: Checking for existing ADVM/ACFS installation.
ACFS-9392: Validating ADVM/ACFS installation files for operating system.
ACFS-9393: Verifying ASM Administrator setup.
ACFS-9308: Loading installed ADVM/ACFS drivers.
ACFS-9154: Loading 'oracleoks.ko' driver.
ACFS-9154: Loading 'oracleadvm.ko' driver.
ACFS-9154: Loading 'oracleacfs.ko' driver.
ACFS-9327: Verifying ADVM/ACFS devices.
CFS-9156: Detecting control device '/dev/asm/.asm_ctl_spec'.
ACFS-9156: Detecting control device '/dev/ofsctl'.
ACFS-9322: completed
#
我们首先需要创建一个磁盘组进而才能在其上构建ACFS文件系统。
$ sqlplus / as sysasm
SQL> create diskgroup ACFS
disk 'ORCL:ASMDISK5', 'ORCL:ASMDISK6'
attribute 'COMPATIBLE.ASM' = '11.2', 'COMPATIBLE.ADVM' = '11.2';
Diskgroup created.
SQL>
虽然从技术上说,可以支持在一个ASM磁盘组里既存放数据库文件也存放ACFS文件,但是我推荐的使用方式是,为ACFS卷使用独立的ASM磁盘组,这样不但提供了功能/角色的分离,而且对数据库文件来说还存在着潜在的性能益处。
接下来我们检查一下所有磁盘组的AU Size:
SQL> select group_number "Group#", name "Name", allocation_unit_size "AU size"
from v$asm_diskgroup_stat;
Group# Name AU size
---------- -------- ----------
1 ACFS 1048576
2 DATA 1048576
SQL>
上面显示两个磁盘组都是1MB的AU Size,后面当我们讨论卷文件区大小的时候还会提到它。
接下来我们在之前创建的ACFS磁盘组中创建一些卷:
$ asmcmd volcreate -G ACFS -s 4G VOL1
$ asmcmd volcreate -G ACFS -s 2G VOL2
$ asmcmd volcreate -G ACFS -s 1G VOL3
获取卷信息
$ asmcmd volinfo -a
Diskgroup Name: ACFS
Volume Name: VOL1
Volume Device: /dev/asm/vol1-142
State: ENABLED
Size (MB): 4096
Resize Unit (MB): 32
Redundancy: MIRROR
Stripe Columns: 4
Stripe Width (K): 128
Usage:
Mountpath:
Volume Name: VOL2
Volume Device: /dev/asm/vol2-142
State: ENABLED
Size (MB): 2048
Resize Unit (MB): 32
Redundancy: MIRROR
Stripe Columns: 4
Stripe Width (K): 128
Usage:
Mountpath:
Volume Name: VOL3
Volume Device: /dev/asm/vol3-142
State: ENABLED
Size (MB): 1024
Resize Unit (MB): 32
Redundancy: MIRROR
Stripe Columns: 4
Stripe Width (K): 128
Usage:
Mountpath:
$
卷在创建后会自动的enable,主机重启后,对于oracle restart环境,我们需要手工装载ADVM/ACFS驱动,再enable我们所创建的卷。
ASM会为每一个卷创建一个卷文件。在一个冗余的磁盘组中,每一个卷都会有一个dirty region logging (DRL)文件。
可以通过以下查询获得一些卷文件的信息:
SQL> select file_number "File#", volume_name "Volume", volume_device "Device", size_mb "MB", drl_file_number "DRL#"
from v$asm_volume;
File# Volume Device MB DRL#
------ ------ ----------------- ----- ----
256 VOL1 /dev/asm/vol1-142 4096 257
259 VOL2 /dev/asm/vol2-142 2048 258
261 VOL3 /dev/asm/vol3-142 1024 260
SQL>
除了卷名称,设备名和卷大小以外,还显示了每一个卷设备的ASM文件编号256,259,262,以及和这个ASM文件相关的DRL文件号,例如上面输出结果中的257,258,259。
译者注:相当于每一个卷的创建会在ASM磁盘中产生2个文件,一个文件是其卷本身,一个是和卷相关的DRL文件。
我们可以通过内部视图x$kffxp查看其中一个卷文件的区分布信息:
SQL> select xnum_kffxp "Extent", au_kffxp "AU", disk_kffxp "Disk"
from x$kffxp
where group_kffxp=2 and number_kffxp=261
order by 1,2;
Extent AU Disk
---------- ---------- ----------
0 6256 0
0 6256 1
1 6264 0
1 6264 1
2 6272 1
2 6272 0
3 6280 0
3 6280 1
...
127 7272 0
127 7272 1
2147483648 6252 0
2147483648 6252 1
2147483648 4294967294 65534
259 rows selected.
SQL>
首先要注意的是,每一个区都被做了镜像,因为这个卷是在一个normal冗余的磁盘组中。
我们也观察到卷文件261有128个区,卷的大小是1个G,这意味着每一个区有8MB或者说8个AU,这里的关键是每个卷文件有它自己的区大小,这一点跟标准的ASM文件不一样,它不会从磁盘组继承区大小。
对于ASM文件来说,在ASM 11.1版本之前,extent的大小是固定的,等于AU的大小,在ASM 11.1版本之后,出现了可变extent,可变extent的出现是为了更好的支持大数据文件,减少对ASM和数据库实例的SGA要求、提升创建文件和打开文件等操作的性能,初始化的extent大小等于磁盘组的AU_SIZE设定值,随着一个文件分配的extent越来越多,extent的size会按照4或16倍的AU_SIZE增大。这个特性在文件新建或者resize的时候自动起作用,当然ASM磁盘组的属性值COMPATIBLE.ASM 和COMPATIBLE.RDBMS要设置为大于等于11.1。
ASM based cluster file systems
我们现在可以基于上面创建的卷来在其上构建ACFS文件系统了(当然需要通过root用户来操作):
# mkdir /acfs1
# mkdir /acfs2
# mkdir /acfs3
# chmod 777 /acfs?
# /sbin/mkfs -t acfs /dev/asm/vol1-142
mkfs.acfs: version = 11.2.0.3.0
mkfs.acfs: on-disk version = 39.0
mkfs.acfs: volume = /dev/asm/vol1-142
mkfs.acfs: volume size = 4294967296
mkfs.acfs: Format complete.
# /sbin/mkfs -t acfs /dev/asm/vol2-142
mkfs.acfs: version = 11.2.0.3.0
mkfs.acfs: on-disk version = 39.0
mkfs.acfs: volume = /dev/asm/vol2-142
mkfs.acfs: volume size = 2147483648
mkfs.acfs: Format complete.
# /sbin/mkfs -t acfs /dev/asm/vol3-142
mkfs.acfs: version = 11.2.0.3.0
mkfs.acfs: on-disk version = 39.0
mkfs.acfs: volume = /dev/asm/vol3-142
mkfs.acfs: volume size = 1073741824
mkfs.acfs: Format complete.
# mount -t acfs /dev/asm/vol1-142 /acfs1
# mount -t acfs /dev/asm/vol2-142 /acfs2
# mount -t acfs /dev/asm/vol3-142 /acfs3
# mount | grep acfs
/dev/asm/vol1-142 on /acfs1 type acfs (rw)
/dev/asm/vol2-142 on /acfs2 type acfs (rw)
/dev/asm/vol3-142 on /acfs3 type acfs (rw)
拷贝一些文件到新创建的文件系统中:
$ cp diag/asm/+asm/+ASM/trace/* /acfs1
$ cp diag/rdbms/db/DB/trace/* /acfs1
$ cp oradata/DB/datafile/* /acfs1
$ cp diag/asm/+asm/+ASM/trace/* /acfs2
$ cp oradata/DB/datafile/* /acfs2
$ cp fra/DB/backupset/* /acfs3
检查使用的空间是否有变化:
$ strings /tmp/ASMspfile.backup
$ df -h /acfs?
Filesystem Size Used Avail Use% Mounted on
/dev/asm/vol1-142 4.0G 1.3G 2.8G 31% /acfs1
/dev/asm/vol2-142 2.0G 1.3G 797M 62% /acfs2
/dev/asm/vol3-142 1.0G 577M 448M 57% /acfs3
我们增加一个盘到ACFS磁盘组中,由于这个操作改变了磁盘组的配置,会触发磁盘组的重平衡操作,我们观察一下重平衡操作的过程:
SQL> alter diskgroup ACFS add disk 'ORCL:ASMDISK4';
Diskgroup altered.
SQL>
从alert 文件中获得重平衡操作进程ARB0的PID号:
$ crsctl stat res ora.asm -p | egrep "ASM_DISKSTRING|SPFILE"
$ tail alert_+ASM.log
Sat Feb 15 12:44:53 2014
SQL> alter diskgroup ACFS add disk 'ORCL:ASMDISK4'
NOTE: Assigning number (2,2) to disk (ORCL:ASMDISK4)
...
NOTE: starting rebalance of group 2/0x80486fe8 (ACFS) at power 1
SUCCESS: alter diskgroup ACFS add disk 'ORCL:ASMDISK4'
Starting background process ARB0
Sat Feb 15 12:45:00 2014
ARB0 started with pid=27, OS id=10767
...
然后通过tail命令查看ARB0进程的跟踪文件获得重平衡的过程信息:
$ tail -f ./+ASM_arb0_10767.trc
*** ACTION NAME:() 2014-02-15 12:45:00.151
ARB0 relocating file +ACFS.1.1 (2 entries)
ARB0 relocating file +ACFS.2.1 (1 entries)
ARB0 relocating file +ACFS.3.1 (42 entries)
ARB0 relocating file +ACFS.3.1 (1 entries)
ARB0 relocating file +ACFS.4.1 (2 entries)
ARB0 relocating file +ACFS.5.1 (1 entries)
ARB0 relocating file +ACFS.6.1 (1 entries)
ARB0 relocating file +ACFS.7.1 (1 entries)
ARB0 relocating file +ACFS.8.1 (1 entries)
ARB0 relocating file +ACFS.9.1 (1 entries)
ARB0 relocating file +ACFS.256.839587727 (120 entries)
*** 2014-02-15 12:46:58.905
ARB0 relocating file +ACFS.256.839587727 (117 entries)
ARB0 relocating file +ACFS.256.839587727 (1 entries)
ARB0 relocating file +ACFS.257.839587727 (17 entries)
ARB0 relocating file +ACFS.258.839590377 (17 entries)
*** 2014-02-15 12:47:50.744
ARB0 relocating file +ACFS.259.839590377 (119 entries)
ARB0 relocating file +ACFS.259.839590377 (1 entries)
ARB0 relocating file +ACFS.260.839590389 (17 entries)
ARB0 relocating file +ACFS.261.839590389 (60 entries)
ARB0 relocating file +ACFS.261.839590389 (1 entries)
...
我们看到重平衡的过程是针对每一个ASM文件做重平衡,这一行为跟数据库文件的重平衡是完全一致的,ASM的1-9号元信息文件首先被重平衡,ASM然后重平衡卷文件256,DRL文件257,如此继续。
从这一点可以看出,ASM重平衡是卷文件而不是存储在操作系统中的文件。
当ASM的磁盘offline时,ASM会创建一个staleness目录,用来跟踪这个offline的磁盘哪些区发生了变化,一旦磁盘重新online,就可以使用这些信息做一个快速的镜像同步。
但是这个功能在11.2版本对卷文件还是不可用的,一旦磁盘online,ASM会重建整个磁盘(offline)的上的内容。
但是在12.1版本以后,对于卷文件也支持了快速镜像同步功能。
ASM磁盘组可以被使用来构建一个通用的集群文件系统ACFS,通过在磁盘组之上创建ASM卷来做到这一点,它所暴露给操作系统的就是一个标准的块设备。
对于做了冗余的磁盘组来说,可以在系统级别起到保护用户文件的作用,ASM通过对于卷文件的每个区做镜像来达到数据保护的目的,卷文件有它自己的区大小,它不会从ASM磁盘组上继承区大小。
最后,ASM磁盘组的重平衡级别是ASM的每个卷文件,而不是操作系统级别看到的一个个的OS文件。