Oracle数据库的ORA-00257故障解决过程

概述：

　　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>

　　5、小结

　　造成本次故障的原因由两方面同时发生所造成的：

　　·其一是Flash_Recovery_Area空间缺省安装时比较小，只有2GB，容易用完；

　　·其二是由于采用归档方式通过Veritas备份，由于备份软件没有运行，造成归档日志没有及时删除。

　　从本次故障解决处理中，我们可以得出经验教训：

　　·Oracle 10g数据库物理空间管理方式与以前Oracle发生了变化，对归档日志所在的Flash_Recovery_Area空间进行了另外限制；
　
　　·对数据库系统管理员要对Oracle数据库归档日志、备份软件运行状况定期检查，提前发现、处理可能发生的故障。 

时间： 2024-10-28 11:12:02

Oracle数据库的ORA-00257故障解决过程的相关文章

plsql连接oracle数据库报ora 12154错误解决方法_oracle

plsql连接oracle数据库报ora 12154错误 今天遇到一个问题,使用sqlplus能够连接到远程的数据库,但是使用plsql却连接不上,报错"ORA-12154: TNS: 无法解析指定的连接标识符" 解决方法如下: 1.先检查服务器端的监听服务是否打开,如果没有打开请启动其监听 客户端:tnsping <tns_name> 服务器Linux下: #>lsnrctl status 查看监听状态 #>lsnrctl start 启动监听 2.通过Sql

Oracle数据库TNS常见错误的解决方法汇总_oracle

TNS是Oracle Net的一部分,是专门用来管理和配置Oracle数据库和客户端连接的一个工具,在大多数情况下客户端和数据库要通讯,就必须配置TNS.本文主要讲述了Oracle数据库TNS常见错误的解决方法如下: 1.ORA-12541:TNS:没有监听器 原因:没有启动监听器或者监听器损坏.若是前者,使用命令net start OracleOraHome10gTNSListener(名字可能有出入)即可;如果是后者,则使用"Net Configuration Assistant"

.NET平台开源项目速览(7)关于NoSQL数据库LiteDB的分页查询解决过程

原文:.NET平台开源项目速览(7)关于NoSQL数据库LiteDB的分页查询解决过程 在文章:这些.NET开源项目你知道吗?让.NET开源来得更加猛烈些吧!(第二辑) 与 .NET平台开源项目速览(3)小巧轻量级NoSQL文件数据库LiteDB中,介绍了LiteDB的基本使用情况以及部分技术细节,我还没有在实际系统中大量使用,但文章发布后,有不少网友( loogn)反应在实际项目中使用过,效果还可以吧.同时也有人碰到了关于LiteDB关于分页的问题,还不止一个网友,很显然这个问题从我的思考上来

Oracle数据库并行查询出错的解决方法_oracle

Oracle的并行查询是使用多个操作系统级别的Server Process来同时完成一个SQL查询,本文讲解Oracle数据库并行查询出错的解决方法如下: 1.错误描述 ORA-12801: 并行查询服务器P007中发出错误信号 ORA-01722:无效数字 12801.00000 -"error signaled in parallel query server %s" *Cause: A parallel query server reached an exception cond

Oracle数据库的ORA-00257故障解决过程(转载）

在导入一个2G的备份文件时,数据库报ORA-00257故障,找到这篇文章.转自http://dev.yesky.com/438/2525938.shtml 概述: Oracle数据库是目前业界最常用的大型数据库系统,我在实际项目中遇到出现ORA-00257错误(空间不足错误),通过查找资料,绝大部分说这是由于归档日志太多,占用了全部的硬盘剩余空间导致的,通过简单删除日志或加大存储空间就能够解决.但是我在Oracle 10g上发现,存储空间还有很大,却也报这个错误.原来是Oracle 10g中新的

Oracle数据库实例的启动和关闭过程

Oracle数据库实例的启动,严格来说应该是实例的启动,数据库仅仅是在实例启动后进行装载.Oracle数据启动的过程被划分为 几个不同的步骤,在不同的启动过程中,我们可以对其实现不同的操作,系统修复等等工作,因此了解Oracle数据启动.关闭是非常 有必要的.下面详细了Oracle Database 10g 数据库启动及关闭的过程. 一.数据库实例的启动 启动命令:starup [force][restrict] [pfile=...] [nomount] [mount] [open] 启动过程

Oracle数据库TNS常见错误的解决办法

  1.ORA-12541:TNS:没有监听器 原因:没有启动监听器或者监听器损坏.若是前者,使用命令net start OracleOraHome10gTNSListener(名字可能有出入)即可;如果是后者,则使用"Net Configuration Assistant"工具向导之"监听程序配置"增加一个监听器即可(基本不用写任何信息,一路OK.在添加之前可能需要把所有的监听器先删!) 2.ORA-12500:TNS:监听程序无法启动专用服务器进程或ORA-12

Oracle数据库启动ORA-08103错误提示解决办法

数据库在open过程报ORA-08103错误导致数据库无法正确启动  代码如下 复制代码 Fri Jul 18 22:02:51 2014 SMON: enabling tx recovery Fri Jul 18 22:02:51 2014 Errors in file d:＼oracle＼product＼10.2.0＼admin＼kemu3＼udump＼kemu3_ora_29788.trc: ORA-00604: ?? SQL ?? 1 ???? ORA-08103: ??????   F

Oracle数据库自动增长列的实现过程

◆1.创建序列 -- Create sequence create sequence INNERID minvalue 1 maxvalue 99999999999999 start with 1 increment by 1 cache 20 order; ◆2.--INNERID.currval 指当前序列 --INNERID.nextval 指下一个序列 insert into admin values (INNERID.nextval,'a'); insert into admin va