遇到ASM的两个BUG

最近在ASM上遇到几个BUG，这里简单记录下来。

SQL> select * from v$version;

BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bi
PL/SQL Release 10.2.0.3.0 - Production
CORE 10.2.0.3.0 Production

TNS for Solaris: Version 10.2.0.3.0 - Production
NLSRTL Version 10.2.0.3.0 - Production

BUG 1：V$ASM_DISK和V$ASM_DISKGROUP显示的剩余空间不一致。
--database 实例
SQL> select total_mb,free_mb from v$asm_diskgroup;

TOTAL_MB FREE_MB
---------- ----------
307201 100536

SQL> select total_mb,free_mb from v$asm_disk;

TOTAL_MB FREE_MB
---------- ----------
102399 0
204802 0

这个可能oracle认为不算bug，因为在asm实例查是没有问题的:
--ASM 实例
SQL> select free_mb,total_mb from v$asm_diskgroup;

FREE_MB TOTAL_MB
---------- ----------
98419 307201

SQL> select free_mb,total_mb from v$asm_disk;

FREE_MB TOTAL_MB
---------- ----------
0 500
0 500
16905 102399
81514 204802

在这里的查询结果看，还是正确的。
oracle文档没有明确说明在database实例查询时结果是不一致的（很多asm视图在数据库实例是没有结果的，但文档都有说明），因此这里也把它归结为BUG吧。

BUG 2:ORA-15041: diskgroup space exhausted

完整的报警信息如下：
Fri Oct 19 23:52:00 2007
Errors in file /oracle/app/admin/pre/bdump/prerac1_arc1_3549.trc:
ORA-19504: failed to create file "+DATA/archivelog/1_84_634432026.dbf"
ORA-17502: ksfdcre:4 Failed to create file +DATA/archivelog/1_84_634432026.dbf
ORA-15041: diskgroup space exhausted

尝试手工归档失败：
SQL> alter system archive log current;

alter system archive log current

ORA-16038: log 4 sequence# 84 cannot be archived
ORA-19504: failed to create file ""
ORA-00312: online log 4 thread 1: '+DATA/onlinelog/redo1_4_1.log'
ORA-00312: online log 4 thread 1: '+DATA/onlinelog/redo1_4_2.log'

这个问题之前遇到过，但没有深究，当时删除了一些归档释放部分空间后，重启实例就在表面上解决问题了，但今天发现问题没有这么简单，因为从查询结果看，空间还是足够的：
这是asmcmd的查看结果：
ASMCMD> lsdg
State Type Rebal Unbal Sector Block AU Total_MB Free_MB Req_mir_free_MB Usable_file_MB Offline_disks Name
MOUNTED EXTERN N N 512 4096 1048576 307201 100552 0 100552 0 DATA/

这是从视图查看的结果：
SQL> select total_mb,free_mb from v$asm_diskgroup;

TOTAL_MB FREE_MB
---------- ----------
307201 100536

从两个查询结果看都有100多G的空间空间，但是在归档500多M的日志的时候仍然会包空间不足。
上metalink查了一下，发现这又是一个bug：DISKGROUP组内的disk使用不能自动均衡，导致其中一个磁盘空间爆满，不能创建新文件。
原因是ASM会尝试把数据分布在所有的磁盘中，如果其中一个disk满了，即使其实的磁盘有足够的空闲空间也不能创建新文件了。
触发这个BUG的条件有两个：
1、diskgroup只有2块磁盘
2、两个磁盘的尺寸不一致。
很不幸，我的环境完全满足这两个条件。这个bug在11g会被修正，目前对于这个问题，oracle提供了一个解决方法：REBALANCE磁盘组。
要注意，重平衡磁盘组要把ASM磁盘组的数据重新分配空间，这个工作非常耗费资源，在正式环境不要轻易执行这个命令：

SQL> ALTER DISKGROUP DATA REBALANCE POWER 11;

Diskgroup altered.

其中11可以替换为1-11之间的任意整数，数值越大，重组越彻底，耗费时间就越长。

发出这个命令后，在ASM实例查询v$asm_operation来看ASM重组的进度：
SQL> select * from v$asm_operation;

GROUP_NUMBER OPERATION STATE POWER ACTUAL SOFAR EST_WORK EST_RATE EST_MINUTES
------------ ---------- -------- ---------- ---------- ---------- ---------- ---------- -----------
1 REBAL RUN 11 11 4395 36847 771 42

SQL> /

GROUP_NUMBER OPERATION STATE POWER ACTUAL SOFAR EST_WORK EST_RATE EST_MINUTES
------------ ---------- -------- ---------- ---------- ---------- ---------- ---------- -----------
1 REBAL RUN 11 11 8132 47805 790 50

REBAL是REBALANCE的所写。

再查看V$ASM_DISK的情况：
SQL> select free_mb,total_mb from v$asm_disk;

FREE_MB TOTAL_MB
---------- ----------
0 500
0 500
16905 102399
81514 204802

隔一段时间后再次查询：

SQL> /

FREE_MB TOTAL_MB
---------- ----------
0 500
0 500
17308 102399
81111 204802

可见，ASM磁盘组中的磁盘的使用率正在变化。

此时在database实例中尝试归档：
SQL> alter system archive log current;

System altered

可以成功归档。这个命令执行起来可能有点慢，因为ASM数据重组进程与归档进程在空间使用上冲突，ASM重组进程会阻塞归档进程，直到归档需要的空间重组完成。

至此，这个bug得到暂时解决。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/231499/viewspace-63870/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/231499/viewspace-63870/