|
【赛迪网－it技术报道】oracle数据库是目前业界最常用的大型数据库系统，我在实际项目中遇到了ora-00257错误（空间不足错误），通过查找资料，绝大部分说这是由于归档日志太多，占用了全部的硬盘剩余空间导致的，通过简单删除日志或加大存储空间就能够解决。但是我在oracle 10g上发现，存储空间还有很大，却也报这个错误。原来是oracle 10g中新的特性，对flash recovery的管理导致的。
1、软硬件环境
服务器hp proliant dl580g4（intel xeon 3.16ghz/4gb/ 72.8*4/raid4)
操作系统red flag dc server release 5.0 (trinity) for x86-64 linux
数据库oracle 10.2.0.1.0
2、问题现象
数据库系统已经试运行了半个多月，在7月24日晚上连接数据库后做数据更新时出现ora-00257错误，如下图。
提示归档错误，通过查找oracle错误代码，解释为硬盘空间不足，需要删除归档日志增加空间，但是服务器可用空间200gb，目前只用了10gb左右，这是为什么呢？
3、诊断过程：
(1)查看oracle数据库归档日志情况
[root@hrmsdb /]# cd /oracle/flash_recovery_area/hkchr/archivelog
[root@hrmsdb archivelog]# ls
2006_07_04 2006_07_13 2006_07_17 2006_07_20 2006_07_23
2006_07_11 2006_07_14 2006_07_18 2006_07_21 2006_07_24
2006_07_12 2006_07_15 2006_07_19 2006_07_22 2006_07_25
[root@hrmsdb archivelog]# cd 2006_07_25
[root@hrmsdb 2006_07_25]# ls
[root@hrmsdb 2006_07_25]# cd ../2006_07_24
[root@hrmsdb 2006_07_24]# ls
o1_mf_1_92_2d933vgb_.arc o1_mf_1_96_2d954ns7_.arc o1_mf_1_98_2d969d5h_.arc
o1_mf_1_95_2d9537cs_.arc o1_mf_1_97_2d956km0_.arc
说明在出现问题之前数据库归档处理一直是正常的。
(2)查看数据库redolog情况
[oracle@hrmsdb ~]$ sqlplus /nolog
sql*plus: release 10.2.0.1.0 - production on 星期二 7月 25 10:44:18 2006
copyright (c) 1982, 2005, oracle. all rights reserved.
sql> connect / as sysdba
已连接。
sql> select * from v$log;
group# thread# sequence# bytes members arc status first_change# first_time
---------- ---------- ---------- ---------- ----------
1 1 101 52428800 1 no current 3621973 24-7月 -06
2 1 99 52428800 1 no inactive 3600145 24-7月 -06
3 1 100 52428800 1 no inactive 3611932 24-7月 -06
发现arc状态为no，表示系统没法自动做归档。
(3)手工切换日志
sql> alter system switch logfile;
alter system switch logfile
*
第1行出现错误:
ora-01013: 用户请求取消当前的操作
在等待长时间没反应后，中断操作，手工切换日志没有成功。
(4)查看oracle数据库后台归档服务进程
[oracle@hrmsdb ~]$ ps -ef|grep oracle
oracle 4601 1 0 jul11 ? 00:00:04 /oracle/product/10.2.0/db_1/bin/
tnslsnr listener -inherit
oracle 5025 1 0 jul11 ? 00:00:00 /usr/bin/ssh-agent -s
oracle 20923 1 0 jul24 ? 00:00:01 ora_pmon_hkchr
oracle 20925 1 0 jul24 ? 00:00:00 ora_psp0_hkchr
oracle 20927 1 0 jul24 ? 00:00:00 ora_mman_hkchr
oracle 20929 1 0 jul24 ? 00:00:01 ora_dbw0_hkchr
oracle 20931 1 0 jul24 ? 00:01:07 ora_lgwr_hkchr
oracle 20933 1 0 jul24 ? 00:00:05 ora_ckpt_hkchr
oracle 20935 1 0 jul24 ? 00:00:01 ora_smon_hkchr
oracle 20937 1 0 jul24 ? 00:00:00 ora_reco_hkchr
oracle 20939 1 0 jul24 ? 00:00:00 ora_cjq0_hkchr
oracle 20941 1 0 jul24 ? 00:00:01 ora_mmon_hkchr
oracle 20943 1 0 jul24 ? 00:00:05 ora_mmnl_hkchr
oracle 20945 1 0 jul24 ? 00:00:00 ora_d000_hkchr
oracle 20947 1 0 jul24 ? 00:00:00 ora_s000_hkchr
oracle 20953 1 0 jul24 ? 00:09:41 ora_arc0_hkchr
oracle 20955 1 1 jul24 ? 00:10:29 ora_arc1_hkchr
oracle 20959 1 0 jul24 ? 00:00:00 ora_qmnc_hkchr
oracle 20967 1 0 jul24 ? 00:00:00 ora_q000_hkchr
oracle 20969 1 0 jul24 ? 00:00:00 ora_q001_hkchr
oracle 21715 1 0 jul24 ? 00:00:19 oraclehkchr (local=no)
oracle 21765 1 0 jul24 ? 00:00:00 ora_j000_hkchr
oracle 21816 1 0 jul24 ? 00:00:00 ora_j001_hkchr
oracle 21832 1 0 jul24 ? 00:00:00 ora_j002_hkchr
oracle 21839 1 0 jul24 ? 00:00:00 ora_j003_hkchr
oracle 21859 1 0 jul24 ? 00:00:00 ora_j004_hkchr
oracle 21861 1 0 jul24 ? 00:00:00 ora_j005_hkchr
oracle 21886 1 0 jul24 ? 00:00:00 ora_j006_hkchr
oracle 21888 1 0 jul24 ? 00:00:00 ora_j007_hkchr
root 23187 23186 0 10:39 ? 00:00:00 login -- oracle
oracle 23188 23187 0 10:39 pts/0 00:00:00 -bash
oracle 23216 23188 0 10:39 pts/0 00:00:00 sqlplus
oracle 23217 23216 0 10:39 ? 00:00:00 oraclehkchr (description=(local=
yes)(address=(protocol=beq)))
root 23224 23223 0 10:40 ? 00:00:00 login -- oracle
oracle 23225 23224 0 10:40 pts/1 00:00:00 -bash
oracle 23310 23225 0 10:46 pts/1 00:00:00 ps -ef
oracle 23311 23225 0 10:46 pts/1 00:00:00 grep oracle
[oracle@hrmsdb ~]$
后台进程都正常运行。
(5)查看flash_recovery_area空间使用情况
[root@hrmsdb /]# cd /oracle
[root@hrmsdb oracle]# ls
admin flash_recovery_area orainventory product
[root@hrmsdb oracle]# du -a -k flash_recovery_area
4 flash_recovery_area/hkchr/onlinelog
42456 flash_recovery_area/hkchr/archivelog/2006_07_15/o1_mf_1_74_2cj1h1jz_.arc
……………….
42448 flash_recovery_area/hkchr/archivelog/2006_07_14/o1_mf_1_68_2cfzwwvt_.arc
512560 flash_recovery_area/hkchr/archivelog/2006_07_14
1469224 flash_recovery_area/hkchr/archivelog
6988 flash_recovery_area/hkchr/backupset/2006_07_04/o1_mf_ncsnf_tag20060704t1
74229_2bng1o0b_.bkp
876916 flash_recovery_area/hkchr/backupset/2006_07_04/o1_mf_nnndf_tag20060704t1
74229_2bng0cx4_.bkp
883908 flash_recovery_area/hkchr/backupset/2006_07_04
883912 flash_recovery_area/hkchr/backupset
2353144 flash_recovery_area/hkchr
2353148 flash_recovery_area
[root@hrmsdb oracle]#
flash_recovery_area空间使用了2.35gb
(6)查看flash_recovery_area空间中各部分使用情况
sql> select * from v$recovery_file_dest;
name space_limit space_used space_reclaimable number_of_files
------------------------------------------------------------
/oracle/flash_recovery_area 2147483648 2134212608 0 35
sql> select * from v$flash_recovery_area_usage;
file_type percent_space_used percent_space_reclaimable number_of_files
------------ ------------------ -------------------------
controlfile 0 0 0
onlinelog 0 0 0
archivelog 69.97 0 40
backuppiece 30.01 0 2
imagecopy 0 0 0
flashbacklog 0 0 0
已选择6行。
发现archivelog占近70％，backuppircr占了30％，这样flash_recovery_area空间的空间已经被完全占据了。
4、解决过程
根据数据库目前可用存储空间为200gb、flash_recovery_area空间为2gb的实际情况，把flash_recovery_area的空间修改为20gb。
sql> alter system set db_recovery_file_dest_size=20g;
系统已更改。
sql> select * from v$recovery_file_dest;
-------------------------------------------------------
name space_limit space_used space_reclaimable number_of_files
----------- ---------- ----------------- -------------
/oracle/flash_recovery_area 2.1475e+10 2264587776 0 38
这时再查看日志的状态，发现redo log处于正常的归档状态。
sql> select * from v$log;
group# thread# sequence# bytes members arc status first_change# first_time
---------- ---------- ---------- ---------- ---------- ---
1 1 101 52428800 1 yes active 3621973 24-7月 -06
2 1 102 52428800 1 no current 3650399 25-7月 -06
3 1 100 52428800 1 yes inactive 3611932 24-7月 -06
sql> select * from v$flash_recovery_area_usage;
file_type percent_space_used percent_space_reclaimable number_of_files
------------ ------------------ ------------------------- ---------------
controlfile 0 0 0
onlinelog 0 0 0
archivelog 7.6 0 43
backuppiece 4.21 0 2
imagecopy 0 0 0
flashbacklog 0 0 0
已选择6行。
sql>
总结
造成本次故障的原因由两方面同时发生所造成的：
?其一是flash_recovery_area空间缺省安装时比较小，只有2gb，容易用完；
?其二是由于采用归档方式通过veritas备份，由于备份软件没有运行，造成归档日志没有及时删除。
从本次故障解决处理中，我们可以得出经验教训：
?oracle 10g数据库物理空间管理方式与以前oracle发生了变化，对归档日志所在的flash_recovery_area空间进行了另外限制；
?对数据库系统管理员要对oracle数据库归档日志、备份软件运行状况定期检查，提前发现、处理可能发生的故障。 |
