问题内容介绍
Automatic Storage Management(ASM) 是Oracle数据库10g中推出的一个非常出色的新特性，它以平台无关的方式提供了文件系统、逻辑卷管理器以及软件RAID等服务。其原理有点儿类似于Linux系统里面LVM 逻辑卷, ASM Diskgroup 类似于Volume Group,由多个ASM disk构成(对应于LVM中的是 Physical Volume),而最终我们在ASM Diskgroup里面创建的文件则就相当于LV。ASM可以条带化和镜像磁盘，从而实现了在数据库被加载的情况下添加或移除磁盘以及自动平衡 I/O 以删除“热点”，相比于传统的文件系统管理方式在IO性能上有较大的提高。
在介绍前我们先来说一个案例，某客户数据库采用了RAC + DG（主库和备库都使用了ASM管理方式），一次客户反映数据库表空间满了，需要增加数据文件来扩展，以为很简单的一个问题,结果...加完一个8G数据文件后 ,前台应用可以正常继续了,但是发现alert日志有大量归档的报错
ORA-16055: FAL request rejected
ARCH: FAL archive failed. Archiver continuing ，更奇怪的是找不到提示中的详细跟踪文件，再次检查发现原来是主库传递归档到备库的时候报错了。此时检查备库同时发现mrp进程已经停止,以为是归档把asm磁盘组空间占满了,但是lsdg发现还剩余100G空间(总共700多G) ,尝试手工启动mrp恢复进程,日志又提示一个编号为183的数据文件不存在（该文件在生产库上对应 +ASM_DATA/orcl/datafile/test10.dbf）,所以无法应用归档,尝试手工创建该文件。
|
SQL> alter database create datafile '/oracle/app/product/db1205/dbs/UNNAMED00183' as '+ASM_DATA/orcl/datafile/ts_emr10.dbf'; alter database create datafile '/oracle/app/product/db1205/dbs/UNNAMED00183' as '+ASM_DATA/orcl/datafile/test10.dbf'
ERROR at line 1: ORA-01119: error in creating database file '+ASM_DATA/orcl/datafile/ts_emr10.dbf' ORA-17502: ksfdcre:4 Failed to create file +ASM_DATA/orcl/datafile/test10.dbf ORA-15041: diskgroup space exhausted |
前面检查过磁盘组还有100G的剩余容量，而这里提示磁盘组空间耗尽，两者之间肯定有一个是误报，而该误报的原因就是下面要讲的ASM的reblance操作。
概念普及
在详细说明本节内容的情况下，需要普及一些小的知识点，当我们向ASM磁盘组中加入磁盘的时候，ASM会自动将磁盘组中每块磁盘上取出部分AU（AU是最小空间分配单元，缺省是1M，每个AU缺省由8个128K条带空间组成）, 写入新加入的磁盘，使所有磁盘含有数据大致相同，当我们从磁盘组中删除磁盘时，同样被删除磁盘中的AU会被平均分配到其他磁盘，这个过程就叫 再平衡(rebalance)。reblance的过程是自动进行的，我们可以设置asm_power_limit参数值来调整平衡的速度。
注：当发生添加/删除磁盘组中磁盘的操作时，ASM能够自动平衡。对于普通的删除操作(无force选项)，被删除的磁盘在该上数据被有效处理前并不会立刻释放，同样，新增磁盘时，在重分配工作完成前，该盘也不会承担I/O负载的工作。
ASM_POWER_LIMIT ：指定磁盘rebalance的程度，有0-11个级别，默认值为1，级别越高，rebalance的操作就会越快被完成(当然这也意味着reblance操作将占用更多的资源，对数据库的性能冲击也越大)，指定级别较低的话，虽然rebalance操作会耗时更久，但对当前系统的IO及负载影响会更少，所以该操作需要根据实际情况慎重选择。另外，这个参数指定的只是一个默认值，在操作过程中，即可以随便动态修改，也可以在语句级命令行时指定power，
如: ALTER DISKGROUP
ASM
磁盘的相关视图
v$asm_disk[_stat] --
查看磁盘及其状态信息
v$asm_diskgroup[_stat] --
查看磁盘组及其状态信息
v$asm_operation --
查看当前磁盘的操作信息
v$asm_client --
查看当前连接的客户端实例信息
v$asm_file --
查看
asm
文件的相关信息
v$asm_template --
查看
asm
文件样本的相关信息
v$asm_alias --
查看
asm
文件的别名信息
先查询一下当前ASM磁盘的状态
|
SQL> select path,total_mb,free_mb from v$asm_disk_stat; PATH TOTAL_MB FREE_MB ------------------------------ ---------- ---------- /dev/vg00/rasm_disk1 153600 20529 /dev/vg00/rasm_disk2 153600 20527 /dev/vg00/rasm_disk3 153600 20532 /dev/vg00/rasm_disk4 153600 20529 /dev/vg00/rasm_disk5 128 0 # 这个 lv 已经完全用光 /dev/vg00/rasm_disk6 102400 13830 |
从这里可以看出，这6个ASM disk都是在OS里面创建的lv，且/dev/vg00/rasm_disk5这个ASM disk已经完全用完，该盘只有128MB的总容量，应该属于误操作加入的磁盘，由于这个磁盘没有剩余空间，而创建数据文件ASM又需要将数据打散到这6个ASM disk上，这就导致了明明磁盘组还有剩余空间，而创建数据文件却提示磁盘组空间耗尽。
再平衡过程
在上述的客户案例中，因为问题出在DG备库上，所以决定修改asm_power_limit参数后重启ASM实例来完成reblance操作。如下
|
SQL> alter system set asm_power_limit=5 scope=spfile;; System altered. SQL> shutdown immediate
ASM diskgroups dismounted
SQL> startup
SQL> select * from v$asm_operation;
SQL> / no rows selected 检查发现没有进行 reblance 操作，继续调整，使用最大值进行 SQL 〉 alter diskgroup ASM_DATA rebalance power 11 wait; Diskgroup altered. |
再次查询v$asm_operation终于看到在rebalance了,按提示估计30分钟就完了,这个提示只是预估值，实际情况一般要比这个长 ,比如我这里大概2个多小时后才完成,此时/dev/vg00/rasm_disk5 的free_mb变为15，隐约觉得这个值还是太小,决定先再次尝试重建183号数据文件，10分钟后提示完成,接着开启mrp进程,因为该服务器物理磁盘性能不佳，应用归档比较慢,2小时候，再次出现ORA-15041: diskgroup space exhausted错误,查询显示/dev/vg00/rasm_disk5这个asm磁盘再次用光,看来这个lv太小导致拖reblance操作的后腿 ,此时为了保险关掉备库数据库实例,然后删除这个asm磁盘。
|
SQL> alter diskgroup asm_data drop disk ASM_DATA_0004
Diskgroup altered.
SQL> select path,total_mb,free_mb from v$asm_disk_stat;
PATH TOTAL_MB FREE_MB ------------------------------ ---------- ---------- /dev/vg00/rasm_disk1 153600 20556 /dev/vg00/rasm_disk2 153600 20556 /dev/vg00/rasm_disk3 153600 20558 /dev/vg00/rasm_disk4 153600 20555 /dev/vg00/rasm_disk6 102400 13704
|
经历了4个小时自动rebalance, 128MB的磁盘被顺利删除，可以看到此时剩余的5个asm磁盘使用率较为平均，此时再次开启mrp恢复进程,直至追平生产库的归档。