近日,处理了一个关于ASM磁盘组空间不足引起的问题。

简单记录如下：

一、问题的反馈

驻地工程师的反馈：

驻地工程师以邮件的形式告知了出现的问题，以及解决该问题的紧急性。

大概这样的描述：告知了巡检时发现了某照片表空间已满，对其进行扩容操作，报错：ORA-15041：DISGROUP "DATA" space exhausted。由于月初需要对上月数据进行考核，客户上传一些照片，此事比较紧急，需立刻解决。

附件中，附带了一些查询信息，如下：
SQL> select group_number,name,total_mb,free_mb from v$ASM_DISKGROUP;

GROUP_NUMBER NAME TOTAL_MB FREE_MB
------------ ------------------------------ ---------- ----------
1 ARCH 860159 405817
2 CRS 30717 29791
3 DATA 1638394 238

SQL> select name,group_number,state,redundancy,total_mb,free_mb,path from v$asm_disk;

NAME GROUP_NUMBER STATE REDUNDA TOTAL_MB
------------------------------ ------------ -------- ------- ----------
FREE_MB
----------
PATH
--------------------------------------------------------------------------------
ARCH_0000 1 NORMAL UNKNOWN 860159
405817
/dev/oracleasm/disks/ARCH

CRS_0002 2 NORMAL UNKNOWN 10239
9931
/dev/oracleasm/disks/VOTE_CRS3

NAME GROUP_NUMBER STATE REDUNDA TOTAL_MB
------------------------------ ------------ -------- ------- ----------
FREE_MB
----------
PATH
--------------------------------------------------------------------------------

CRS_0001 2 NORMAL UNKNOWN 10239
9930
/dev/oracleasm/disks/VOTE_CRS2

DATA_0001 3 NORMAL UNKNOWN 819197
112

NAME GROUP_NUMBER STATE REDUNDA TOTAL_MB
------------------------------ ------------ -------- ------- ----------
FREE_MB
----------
PATH
--------------------------------------------------------------------------------
/dev/oracleasm/disks/DATA2

DATA_0000 3 NORMAL UNKNOWN 819197
126
/dev/oracleasm/disks/DATA1

CRS_0000 2 NORMAL UNKNOWN 10239

NAME GROUP_NUMBER STATE REDUNDA TOTAL_MB
------------------------------ ------------ -------- ------- ----------
FREE_MB
----------
PATH
--------------------------------------------------------------------------------
9930
/dev/oracleasm/disks/VOTE_CRS1

6 rows selected.

二、紧急的处理

连入生成库，查询确实asm空间严重不足了。
ASMCMD> lsdg

State Type Rebal Sector Block AU Total_MB Free_MB Req_mir_free_MB Usable_file_MB Offline_disks Voting_files Name
MOUNTED EXTERN N 512 4096 1048576 860159 405780 0 405780 0 N ARCH/
MOUNTED NORMAL N 512 4096 1048576 30717 29791 10239 9776 0 Y CRS/
MOUNTED EXTERN N 512 4096 1048576 1638394 238 0 238 0 N DATA/

为快速解决问题，让应用跑起来，决定先从如何解决无法扩充表空间的方面进行入手。
想到的是缩减低利用率的表空间。

于是查看表空间的使用情况：
1、发现undo表空间、temp表空间被扩容了很大，可以对其缩减；
2、发现了一些低利用率的表空间，诸如GB级别的只存了几M的数据量，可以考虑缩减；

于是连续使用诸如下面这样的命令：

ALTER DATABASE
TEMPFILE '+DATA/xcky/xckytmp04.dbf'
RESIZE 1024M;

用来实现对可缩减表空间的大小进行缩减。

经过一番空间缩减后，再次查询空间使用率，满足扩容表空间的需求，完成了业务中存储照片表空间的扩容。应用系统使用恢复正常。

三、阶段性回馈

快速回馈驻地工程师问题解决情况。

问题原因是：ASM磁盘组空间不足引起。

1、临时采取的方法是缩减了其它表空间的大小，为/DATA目录释放空间（缩减了undo表空间、temp表空间、其它空间利用率较低的表空间的大小）。

并且，已经新建了一个10G，自动扩展，存储照片的表空间，命名为photo_info47.dbf。

2、但后续建议：

（1）为存储扩容。
按照本环境的ASM规划策略，目前ASM磁盘组中的/DATA已经使用了约1.4T（总大小约为1.5T），/DATA下目前可用空间剩余约50G。

（2）或重新规划asm存储，考虑临时在/ARCH上扩充表空间（目前剩余400G可用），但该/ARCH是用于存放归档文件的，不建议这么做，后续有如果归档剧增，有引发出现hang停数据库的可能。

四、后续解决本质性问题

?

再次连接生产库，查询是否有进一步解决问题的好方法。
先来查询目前空间的大致使用情况。
SQL> conn sys/oracle as sysdba
Connected.
SQL> show user
USER is "SYS"
SQL> select path,total_mb,free_mb from v$asm_disk_stat;