Oracle数据库的ORA-00257故障解决过程
时间:2014-12-11 23:21 来源:linux.it.net.cn 作者:IT
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、问题现象
数据库系统已经试运行了半个多月,在连接数据库后做数据更新时出现ORA-00257错误,提示归档错误,通过查找ORACLE错误代码,解释为硬盘空间不足,需要删除归档日志增加空间,但是服务器可用空间200GB,目前只用了10GB左右,这是为什么呢?
3、诊断过程:
1)查看ORACLE数据库归档日志情况
?
1 <SPAN style="FONT-SIZE: 8pt">[root@hrmsdb /]# cd /oracle/flash_recovery_area/HKCHR/archivelog [root@hrmsdb archivelog]# ls</SPAN>
?
1 <SPAN style="FONT-SIZE: 8pt"> 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 </SPAN>
?
1 <SPAN style="FONT-SIZE: 8pt"> 2006_07_12 2006_07_15 2006_07_19 2006_07_22 2006_07_25 </SPAN>
?
1 <SPAN style="FONT-SIZE: 8pt">[root@hrmsdb archivelog]# cd 2006_07_25</SPAN>
?
1 <SPAN style="FONT-SIZE: 8pt">[root@hrmsdb 2006_07_25]# ls</SPAN>
?
1 <SPAN style="FONT-SIZE: 8pt"> [root@hrmsdb 2006_07_25]# cd ../2006_07_24</SPAN>
?
1 <SPAN style="FONT-SIZE: 8pt">[root@hrmsdb 2006_07_24]# ls</SPAN>
?
1 <SPAN style="FONT-SIZE: 8pt"> 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</SPAN>
说明在出现问题之前数据库归档处理一直是正常的。
2)查看数据库REDOLOG情况
代码
[oracle@hrmsdb ~]$ sqlplus /nologSQL*Plus: Release 10.2.0.1.0 - Production on 星期二 7月 25 10:44:18 2006Copyright (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月 -062 1 99 52428800 1 NO INACTIVE 3600145 24-7月 -063 1 100 52428800 1 NO INACTIVE 3611932 24-7月 -06
发现ARC状态为NO,表示系统没法自动做归档。
3)手工切换日志
?
1
2
3
4
5
6
7 <SPAN style="FONT-SIZE: 8pt">SQL> alter system switch logfile;
alter system switch logfile
*
第 1 行出现错误:
</SPAN>
ORA-01013: 用户请求取消当前的操作
在等待长时间没反应后,中断操作,手工切换日志没有成功。
4)查看Oracle数据库后台归档服务进程
代码
[oracle@hrmsdb ~]$ ps -ef|grep oracleoracle 4601 1 0 Jul11 ? 00:00:04 /oracle/product/10.2.0/db_1/bin/tnslsnr LISTENER -inheritoracle 5025 1 0 Jul11 ? 00:00:00 /usr/bin/ssh-agent -soracle 20923 1 0 Jul24 ? 00:00:01 ora_pmon_hkchroracle 20925 1 0 Jul24 ? 00:00:00 ora_psp0_hkchroracle 20927 1 0 Jul24 ? 00:00:00 ora_mman_hkchroracle 20929 1 0 Jul24 ? 00:00:01 ora_dbw0_hkchroracle 20931 1 0 Jul24 ? 00:01:07 ora_lgwr_hkchroracle 20933 1 0 Jul24 ? 00:00:05 ora_ckpt_hkchroracle 20935 1 0 Jul24 ? 00:00:01 ora_smon_hkchroracle 20937 1 0 Jul24 ? 00:00:00 ora_reco_hkchroracle 20939 1 0 Jul24 ? 00:00:00 ora_cjq0_hkchroracle 20941 1 0 Jul24 ? 00:00:01 ora_mmon_hkchroracle 20943 1 0 Jul24 ? 00:00:05 ora_mmnl_hkchroracle 20945 1 0 Jul24 ? 00:00:00 ora_d000_hkchroracle 20947 1 0 Jul24 ? 00:00:00 ora_s000_hkchroracle 20953 1 0 Jul24 ? 00:09:41 ora_arc0_hkchroracle 20955 1 1 Jul24 ? 00:10:29 ora_arc1_hkchroracle 20959 1 0 Jul24 ? 00:00:00 ora_qmnc_hkchroracle 20967 1 0 Jul24 ? 00:00:00 ora_q000_hkchroracle 20969 1 0 Jul24 ? 00:00:00 ora_q001_hkchroracle 21715 1 0 Jul24 ? 00:00:19 oraclehkchr (LOCAL=NO)oracle 21765 1 0 Jul24 ? 00:00:00 ora_j000_hkchroracle 21816 1 0 Jul24 ? 00:00:00 ora_j001_hkchroracle 21832 1 0 Jul24 ? 00:00:00 ora_j002_hkchroracle 21839 1 0 Jul24 ? 00:00:00 ora_j003_hkchroracle 21859 1 0 Jul24 ? 00:00:00 ora_j004_hkchroracle 21861 1 0 Jul24 ? 00:00:00 ora_j005_hkchroracle 21886 1 0 Jul24 ? 00:00:00 ora_j006_hkchroracle 21888 1 0 Jul24 ? 00:00:00 ora_j007_hkchrroot 23187 23186 0 10:39 ? 00:00:00 login -- oracleoracle 23188 23187 0 10:39 pts/0 00:00:00 -bashoracle 23216 23188 0 10:39 pts/0 00:00:00 sqlplusoracle 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 -- oracleoracle 23225 23224 0 10:40 pts/1 00:00:00 -bashoracle 23310 23225 0 10:46 pts/1 00:00:00 ps -eforacle 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]# lsadmin flash_recovery_area oraInventory product[root@hrmsdb oracle]# du -a -k flash_recovery_area4 flash_recovery_area/HKCHR/onlinelog42456 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_.arc512560 flash_recovery_area/HKCHR/archivelog/2006_07_141469224 flash_recovery_area/HKCHR/archivelog6988 flash_recovery_area/HKCHR/backupset/2006_07_04/o1_mf_ncsnf_TAG20060704T174229_2bng1o0b_.bkp876916 flash_recovery_area/HKCHR/backupset/2006_07_04/o1_mf_nnndf_TAG20060704T174229_2bng0cx4_.bkp883908 flash_recovery_area/HKCHR/backupset/2006_07_04883912 flash_recovery_area/HKCHR/backupset2353144 flash_recovery_area/HKCHR2353148 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 35SQL> select * from v$flash_recovery_area_usage;FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES------------ ------------------ ------------------------- ---------------- -------------- -------------- -------------CONTROLFILE 0 0 0ONLINELOG 0 0 0ARCHIVELOG 69.97 0 40BACKUPPIECE 30.01 0 2IMAGECOPY 0 0 0FLASHBACKLOG 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月 -062 1 102 52428800 1 NO CURRENT 3650399 25-7月 -063 1 100 52428800 1 YES INACTIVE 3611932 24-7月 -06SQL> select * from v$flash_recovery_area_usage;FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES------------ ------------------ ------------------------- ---------------CONTROLFILE 0 0 0ONLINELOG 0 0 0ARCHIVELOG 7.6 0 43BACKUPPIECE 4.21 0 2IMAGECOPY 0 0 0FLASHBACKLOG 0 0 0已选择6行。SQL>
5、小结
造成本次故障的原因由两方面同时发生所造成的:
·其一是Flash_Recovery_Area空间缺省安装时比较小,只有2GB,容易用完;
·其二是由于采用归档方式通过Veritas备份,由于备份软件没有运行,造成归档日志没有及时删除。
从本次故障解决处理中,我们可以得出经验教训:
·Oracle 10g数据库物理空间管理方式与以前Oracle发生了变化,对归档日志所在的Flash_Recovery_Area空间进行了另外限制;
·对数据库系统管理员要对Oracle数据库归档日志、备份软件运行状况定期检查,提前发现、处理可能发生的故障。
(责任编辑:IT)
1、软硬件环境
服务器HP Proliant DL580G4(Intel Xeon 3.16GHz/4GB/ 72.8*4/RAID4)
2、问题现象 3、诊断过程: 1)查看ORACLE数据库归档日志情况
? 说明在出现问题之前数据库归档处理一直是正常的。 2)查看数据库REDOLOG情况
3)手工切换日志
?
ORA-01013: 用户请求取消当前的操作
5)查看FLASH_RECOVERY_AREA空间使用情况
4、解决过程 根据数据库目前可用存储空间为200GB、FLASH_RECOVERY_AREA空间为2GB的实际情况,把FLASH_RECOVERY_AREA的空间修改为20GB。
造成本次故障的原因由两方面同时发生所造成的: ·其一是Flash_Recovery_Area空间缺省安装时比较小,只有2GB,容易用完; ·其二是由于采用归档方式通过Veritas备份,由于备份软件没有运行,造成归档日志没有及时删除。 从本次故障解决处理中,我们可以得出经验教训:
·Oracle 10g数据库物理空间管理方式与以前Oracle发生了变化,对归档日志所在的Flash_Recovery_Area空间进行了另外限制; (责任编辑:IT) |