<<转>>

概述

  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问题的解决(归档程序错误)相关推荐

  1. 解决ORA-00257: 归档程序错误。在释放之前仅限于内部连接

    昨天尝试通过plsqldev尝试连接oracle数据库,报错,提示ORA-00257: 归档程序错误.在释放之前仅限于内部连接 通过查询,得知原因是archivedlog达到了数据库设置的空间限制. ...

  2. 归档程序错误。在释放之前仅限于内部连接

    10.2.0.1的FLASH_RECOVERY_AREA 默认空间为2G. 时间长了没管他,出现下面错误: ORA-00257: 归档程序错误.在释放之前仅限于内部连接 检查alert_log日志原来 ...

  3. ORA-00257: 归档程序错误

    ORA-00257: 归档程序错误.在释放之前仅限于内部连接 数据库突然不能够正常连接,连接出现错误:ORA-00257:   归档程序错误.在释放之前仅限于内部连接   . 首先数据库日志文件有两种 ...

  4. ORA-00257: 归档程序错误 Oracle归档报错处理方式

    Oracle在windows服务器下异常断电或者长时间运行情况下,容易发生ORA-00257: 归档程序错误,此时通过plsql或者sqlplus都会报错异常,该问题处理方式具体如下: "O ...

  5. ORA 00257 归档程序错误 导致无法连接

    问题描述 通过PL/SQL登录数据库报错 用sqlplus工具登录时会hang住 [oracle@db RACDB]$ !sql sqlplus / as sysdbaSQL*Plus: Releas ...

  6. ORA-00257: 归档程序错误-增加空间、删除日志、关闭日志

    方案一:增加空间 1.在dos命令下切换到sqlplus命令 sqlplus / as sysdba; 2.查看归档日志占比 select * from v$flash_recovery_area_u ...

  7. explorer.exe应用程序错误说明 0X000000该内存不能为read的解决方法

    0X000000该内存不能为read的解决方法 出现这个现象有方面的,一是硬件,即内存方面有问题,二是软件,这就有多方面的问题了. 一:先说说硬件: 一般来说,电脑硬件是很不容易坏的.内存出现问题的可 ...

  8. winlogon.exe应用程序错误的解决方法

    winlogon.exe应用程序错误的解决方法 参考文章: (1)winlogon.exe应用程序错误的解决方法 (2)https://www.cnblogs.com/haitao-fan/archi ...

  9. 完美解决小程序一维数组循环渲染列表不够用问题

    完美解决小程序一维数组循环渲染列表不够用问题 参考文章: (1)完美解决小程序一维数组循环渲染列表不够用问题 (2)https://www.cnblogs.com/jessical626/p/6363 ...

  10. 在 Linux 上找出并解决程序错误的主要方法【转】

    在 Linux 上找出并解决程序错误的主要方法[转] 参考文章: (1)在 Linux 上找出并解决程序错误的主要方法[转] (2)https://www.cnblogs.com/sky-heaven ...

最新文章

  1. IBM 内核惨败:20 亿美元打水漂 !
  2. xen虚拟机的启动(引导)方式
  3. matlab结课论文_科研小班 | 加州大学伯克利分校 | 物理、电子工程:MATLAB信号和数据处理课题...
  4. 【安全漏洞】CVE-2021-42287CVE-2021-42278 域内提权
  5. 360加固逆向脱壳之过反调试
  6. 瑞斯康达nms_瑞斯康达iTN产品资料
  7. 谷歌安全研究员发现3个 Apache Web 服务器软件缺陷
  8. Java调用Tuxedo方案浅析
  9. vscode 字体放大缩小快捷键
  10. 大学计算机基础知识说课,计算机基础说课课件
  11. 微信支付(PC扫码支付和H5公众号支付)
  12. 微信小程序 选项卡 swiper默认高度150px(让高度实现自适应)解决方法
  13. redis实现队列的几种方式(LPUSH/BRPOP,发布/订阅模式,stream)
  14. OMPL官方教程学习State Validity Checking
  15. python画笔粗细函数_Python 画图基础操作详解
  16. 中国计算机科学院士,盘点!获奖者中,84位院士、10位国家最高科学技术奖得主,高校科学家表现出色...
  17. 【计算机体系结构】计算机体系结构(1) 计算机系统结构的设计基础
  18. Games202 Lecture3-4之SAT: Summed Area Table
  19. Linux窗口和Win命令窗口查看mysql bit类型的值
  20. Windows 安全中心空白无选项解决办法

热门文章

  1. 我的世界观【文津图书奖获奖作品】
  2. DEV C++下载,百度云盘,干净
  3. ssm基于WEB的房屋出租管理系统的设计与实现161620
  4. HCNA-Storage (H13-611)题库 v4.0
  5. Altium Designer安装包下载
  6. C# 开发Chrome内核浏览器(WebKit.net)
  7. 页面修饰框架SiteMesh的简单使用
  8. Anaconda下载速度慢
  9. 基于javafx+sqlserver的仓库管理系统
  10. Apizza在线接口工具动态绑定API参数依赖