ASM磁盘空间假装耗尽，ORA-15041: DISKGROUP SPACE EXHAUSTED

今天遇到类似的问题,在网上搜索下解决办法:

 

引用:http://wangwei.cao.blog.163.com/blog/static/1023625262011799144829/

转载一个组内以兄弟昨晚遇到的问题，及处理方法，以备不时之需。。。。

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

今晚又一次遇到了ASM磁盘空间假耗尽的现象，写一下大致的过程，详细解释可以看我们老大的BLOG，

http://zhang41082.itpub.net/post/7167/486166

1.发现DW库DW001又报空间问题了：

23:30:02 database DW tablespace DW001 min datafile size 25G > 24G

2.然后想着去添加一个数据文件，结果报错：

 

23:31:57 sys@warehous>alter tablespace DW001 add datafile '+DATA/oradata/warehouse/dw001_20.dbf' size 1024m autoextend on next 10m maxsize unlimited;

alter tablespace DW001 add datafile '+DATA/oradata/warehouse/dw001_20.dbf' size 1024m autoextend on next 10m maxsize unlimited*

ERROR at line 1:

ORA-01119: error in creating database file '+DATA/oradata/warehouse/dw001_20.dbf'

ORA-17502: ksfdcre:4 Failed to create file +DATA/oradata/warehouse/dw001_20.dbf

ORA-15041: diskgroup space exhausted

3.去检查了一下ASM的空间：

23:30:05 idle>select total_mb, free_mb from v$asm_diskgroup; 

  TOTAL_MB    FREE_MB

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

   1879014     380096

还剩下370G+的空间，报diskgroup space exhausted，明显是坑爹的

4.去check了每个asm_disk的free空间，果然是上面的问题：

 

23:36:58 idle>select path,total_mb,free_mb from v$asm_disk_stat;

PATH    TOTAL_MB    FREE_MB

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

ORCL:ASMDISK01

    511993          0

ORCL:ASMDISK02

    511993          0

ORCL:ASMDISK03

    204797          0

ORCL:ASMDISK04

    204797          0

ORCL:ASMDISK05

    240637     206706

ORCL:ASMDISK06

    204797     173390

5.去将空间rebalance掉

23:43:43 idle>alter diskgroup DATA rebalance power 10;

Diskgroup altered.

Elapsed: 00:00:02.32

6.一会以后有空间出来了

 

23:44:17 idle> select path,total_mb,free_mb from v$asm_disk_stat;

PATH  TOTAL_MB    FREE_MB

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

ORCL:ASMDISK01

    511993        401

ORCL:ASMDISK02

    511993        407

ORCL:ASMDISK03

    204797        161

ORCL:ASMDISK04

    204797        160

ORCL:ASMDISK05

    240637     206096

ORCL:ASMDISK06

    204797     172871

6 rows selected.

Elapsed: 00:00:00.00

7.再去添加数据文件，OK了

23:44:43 sys@warehous>alter tablespace DW001 add datafile '+DATA/oradata/warehouse/dw001_20.dbf' size 1024m autoextend on next 10m maxsize unlimited;  

Tablespace altered.

Elapsed: 00:00:28.25

原因分析：

第一反应就是这肯定是个BUG！登陆ML开始狂搜，结果发现碰到类似问题的人太多了，而且ASM类似的BUG也是一大堆，没眉目了。其中一个最引起注意的是这么一个地方（ML:389877.1），大概意思就是说：

一般我们都是去V$ASM_DISKGROUP或者V$ASM_DISK中来查看ASM组总共有多少空间，还剩余了多少空间，大多数情况下呢，这个数字是准确的，但是有时候呢，ORACLE会忽悠你！ASM中记录这些空间使用信息的地方有两个，上面只是其中一个地方（叫disk directory），还有另外一个地方(allocation tables)。那么当你在RESIZE的时候呢，如果这个RESIZE失败了，那么DIRECTORY中的数字是不会更新的，这是对的，因为本来空间就没分配成功嘛，但是，ALLOCATION TABLE是会更新的，所以就导致了你从V$ASM_DISKGROUP中看到有很多空间信息，但是干着急就是没法用。那么怎么确认是否有这种问题存在呢？

select group_number,file_number,bytes,space from v$asm_file，在这个SQL的返回结果中，BYTES是数据文件实际的大小，而SPACE是数据文件占用的ASM空间的大小，而ASM磁盘有三种冗余方式，分别是EXTERNAL/NORMAL/HIGH，这三种情况下，SPACE分别应该是BYTES的1倍（也就是基本相等）、两倍和三倍。如果某些数据文件不符合上面这个对应关系，那就应该是你撞上这个问题了。可是查下来这个问题在我这里不存在，SPACE确实比BYTES大，但都只是大了一点点。（对于上面这种情况，ML上面的做法是先把这个文件OFFLINE，然后备份，然后删除，然后再RESTORE回来，然后再RECOVER，然后再ONLINE，这样就OK了）

后来无头苍蝇一样乱撞吧，挨个看看v$asm开头的视图，结果看到v$asm_disk_stats的时候发现了问题。

select path,total_mb,free_mb from v$asm_disk_stat;

执行这个查询的时候，发现大多数些卷FREE_MB为0了，而有一个卷却有将近900G空闲空间。后来想起来了，当初RMAN复制这个库的时候，因为库正在恢复的时候发现空间很紧张，就加了1T空间上去，然后POWER为5开始REBALANCE，后来发现RMAN的复制很慢，就把REBALANCE POWER改成0了，复制完把这茬给忘了，结果一直都没有REBALANCE（本来想着系统自己的REBALANCE POWER设置为1，它自己会慢慢的REBALANCE的），从而导致了今天的问题。

最终，开启POWER 11的REBALANCE，等每个卷都有不少空间空间的时候开始恢复，报错的地方已经能够过去了，剩下的就是慢慢等着恢复和REBALANCE就是了