今天遇到类似的问题,在网上搜索下解决办法:
引用: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就是了