• [转]ORA00257解决


     原:http://blog.chinaunix.net/u/26381/showart_373304.html

    从Oracle9i开始,借助于UNDO日志文件提供了闪回查询的功能,由于功能也有一定的局限性,也就是说依赖于UNDO日志的事务不能被覆盖,所以在Oracle10g开始又采用了一种新的FlashBack日志来实现这个功能,而且更为强大,可以将数据库退回到过去某个时间点去。这个文件默认最大为2g。但是在一段时间过后,很快就达到了2G,这个时候就会出现ORA-00257错误了。
       两种解决方法:
       第一种 就是关闭闪回日志的功能,这种对于开发环境中不失为一种好方法,因为开发环境中,并不追求数据的可安全性什么的。通过如下语句改变。
       alter database flashback off
           
       第二种 方法就是增大闪回日志文件的最大大小。如下
       alter system set DB_RECOVERY_FILE_DEST_SIZE=10g
       这个时候,你可以去查看v$flash_recovery_area_usage视图中的使用率情况,这个时候发现使用率(PERCENT_SPACE_USED列的值)已经大大降低了。再通过如下语句去查看系统日志文件情况。

       select * from v$log
       会发现现在redo日志文件也可以正常写入,至此问题解决。

    -------------------------------------------------------------------
    讲解Oracle数据库ORA-00257故障的解决过程
    原文:http://developer.weaseek.com/2008/0715/47199469_1.shtml  2008-07-15 15:39:13  来源:赛迪网
    在实际项目中遇到了ORA-00257错误(空间不足错误),通过查找资料,绝大部分说这是由于归档日志太多,占用了全部的硬盘剩余空间导致的,通过简单删除日志或加大存储空间就能够解决。但是我在Oracle 10g上发现,存储空间还有很大,却也报这个错误。原来是Oracle 10g中新的特性,对Flash Recovery的管理导致的。

    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数据库归档日志、备份软件运行状况定期检查,提前发现、处理可能发生的故障。

  • 相关阅读:
    Python元类
    Python接口与归一化设计
    如何使用yum下载rpm包
    浅谈Python的with语句
    搞懂了这几点,你就学会了Web编程
    网络虚拟化技术大观
    Python装饰器
    Kubernetes配置Ceph RBD StorageClass
    编译Kubelet二进制文件
    记一次虚拟机无法挂载volume的怪异问题排查
  • 原文地址:https://www.cnblogs.com/xinyuxin912/p/1428214.html
Copyright © 2020-2023  润新知