最近在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/