在导入一个2G的备份文件时,数据库报ORA-00257故障,找到这篇文章。转自http://dev.yesky.com/438/2525938.shtml
概述:
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数据库归档日志、备份软件运行状况定期检查,提前发现、处理可能发生的故障。
分享到:
相关推荐
本文将详细讲解如何理解和解决“ORA-00257”错误,以及相关的Oracle数据库管理知识。 “ORA-00257”错误通常表示在尝试执行数据库的日志切换或归档操作时遇到了问题,这可能是由于以下原因导致的: 1. **归档日志...
在Oracle数据库管理过程中,遇到ORA-12518错误是较为常见的问题之一。此错误通常发生在客户端试图连接到数据库服务器的过程中,当监听器无法将客户端连接顺利地移交给服务器进程或调度进程时触发。本文旨在详细介绍...
然而,有时在使用Navicat连接Oracle数据库时可能会遇到各种问题,如"ORA-12737 InstantClientLight"错误。本文将深入探讨这个错误及其解决方案,同时也会涉及Navicat与Oracle的集成以及InstantClient的相关知识。 ...
总之,解决ORA-12737错误需要对Oracle数据库的运作机制有一定理解,并结合日志信息进行系统性的排查。通过逐步检查数据库状态、监听器、网络配置、客户端版本以及使用辅助工具,大多数情况下都能找到问题的根源并...
在Oracle数据库的日常管理和运维中,我们经常遇到各种"ORA-"开头的错误代码,这些错误代码是Oracle系统用来标识特定问题的。Oracle数据库是全球广泛使用的数据库管理系统,它提供了复杂的数据存储、处理和管理功能。...
以下是解决Oracle数据库ORA-01196错误的一般方法: 1. **检查控制文件**:首先,确认控制文件是否完整且正确。控制文件存储了数据库的数据文件和日志文件的位置以及状态,如果控制文件损坏,可能会导致ORA-01196...
ORA-04031错误是Oracle数据库中一个常见的内存管理问题,主要涉及到数据库的共享池。当系统尝试分配共享池中的大块连续内存失败时,Oracle会尝试清理和合并内存块,但如果仍然无法满足需求,就会触发此错误。这个...
Oracle 常见故障解决方法 Oracle 是一种关系型数据库管理系统,广泛应用于各种行业和领域。然而,在使用 Oracle 过程中,经常会遇到各种故障和问题,影响系统的稳定性和性能。下面总结了一些常见的 Oracle 故障...
Oracle 数据库 ORA-03113 问题解决方案 在启动数据库时,可能会出现 ORA-03113 错误,该错误通常是由于数据库日志文件的不一致所引起的。为了解决这个问题,我们需要对数据库进行恢复和重置日志文件。下面是解决该...
在使用Oracle Data Pump工具IMPDP(Import Data Pump)进行数据导入的过程中,可能会遇到ORA-39002和ORA-39070等错误。本文将针对这些错误的排查方法进行详细介绍,帮助用户理解问题的原因及解决策略。 ### 错误...
在Oracle数据库管理与维护的过程中,遇到各种错误代码是家常便饭,其中“ORA-227101”错误虽然在题目中被误标,实际案例中展示的是“ORA-27101”错误,这是一个较为常见的问题,通常发生在数据库服务未能正确启动或...
"ORACLE数据库一次意外宕机的分析处理实记(ora-1578)" 在本文中,我们将讲述ORACLE数据库一次意外宕机的分析处理过程。该宕机事件发生在测试环境中的一台装有ORACLE数据库的AIX小机上,导致数据库宕机。我们将从...
ORA-01033是Oracle数据库启动过程中遇到的一种常见错误。当数据库实例在启动过程中无法正常初始化或打开时,就会触发此错误。该错误通常出现在数据库实例启动到系统全局区(SGA)阶段后,但尚未完全加载数据文件之前...
标题和描述中提到的是关于如何解决Oracle数据库系统中出现的Ora-00600错误的故障处理方法。Ora-00600错误是Oracle数据库内部错误,通常表明系统遇到了无法处理的异常情况。这篇文档可能提供了解决这个问题的步骤和...
### Oracle ORA-03113 错误解析及解决方法 ... - 对于Oracle数据库的日志和告警信息进行定期审查,及时发现问题并解决。 通过以上步骤,可以有效地解决ORA-03113错误,并防止类似问题在未来再次发生。
标题中的“navicat链接oracle提示:“ORA-12737”资源包”表明了问题的核心在于Navicat这款数据库管理工具尝试连接Oracle数据库时遇到了错误“ORA-12737”。这个错误通常与Oracle Instant Client有关,它是Oracle...
在Oracle数据库管理过程中,遇到控制文件版本不一致的问题时,通常会收到ORA-00214错误提示。此错误表示数据库中的一个或多个控制文件与其它控制文件版本不匹配,这可能是由于突然断电、硬件故障或其他原因导致的...
Oracle RAC ORA-03113 故障处理是一个复杂的过程,需要遵循严格的步骤,以免引起更多的故障。通过遵循上述步骤,可以成功地处理 ORA-03113 故障,恢复数据库的正常运行。同时,也可以通过不断的学习和实践,提高...