從Oracle9i開始，借助于UNDO日志文件提供了閃回查詢的功能，由于功能也有一定的局限性，也就是說依賴于UNDO日志的事務(wù)不能被覆蓋，所以在Oracle10g開始又采用了一種新的FlashBack日志來實(shí)現(xiàn)這個(gè)功能，而且更為強(qiáng)大，可以將數(shù)據(jù)庫(kù)退回到過去某個(gè)時(shí)間點(diǎn)去。這個(gè)文件默認(rèn)最大為2g。但是在一段時(shí)間過后，很快就達(dá)到了2G，這個(gè)時(shí)候就會(huì)出現(xiàn)ORA-00257錯(cuò)誤了。

兩種解決方法:

第一種 就是關(guān)閉閃回日志的功能，這種對(duì)于開發(fā)環(huán)境中不失為一種好方法，因?yàn)殚_發(fā)環(huán)境中，并不追求數(shù)據(jù)的可安全性什么的。通過如下語句改變。

alter database flashback off

第二種 方法就是增大閃回日志文件的最大大小。如下

alter system set DB_RECOVERY_FILE_DEST_SIZE=10g

這個(gè)時(shí)候，你可以去查看v$flash_recovery_area_usage視圖中的使用率情況，這個(gè)時(shí)候發(fā)現(xiàn)使用率(PERCENT_SPACE_USED列的值)已經(jīng)大大降低了。再通過如下語句去查看系統(tǒng)日志文件情況。

select * from v$log

會(huì)發(fā)現(xiàn)現(xiàn)在redo日志文件也可以正常寫入，至此問題解決。

-------------------------------------------------------------------

在實(shí)際項(xiàng)目中遇到了ORA-00257錯(cuò)誤(空間不足錯(cuò)誤)，通過查找資料，絕大部分說這是由于歸檔日志太多，占用了全部的硬盤剩余空間導(dǎo)致的，通過簡(jiǎn)單刪除日志或加大存儲(chǔ)空間就能夠解決。但是我在Oracle 10g上發(fā)現(xiàn)，存儲(chǔ)空間還有很大，卻也報(bào)這個(gè)錯(cuò)誤。原來是Oracle 10g中新的特性，對(duì)Flash Recovery的管理導(dǎo)致的。

Oracle數(shù)據(jù)庫(kù)是目前業(yè)界最常用的大型數(shù)據(jù)庫(kù)系統(tǒng)，我在實(shí)際項(xiàng)目中遇到了ORA-00257錯(cuò)誤(空間不足錯(cuò)誤)，通過查找資料，絕大部分說這是由于歸檔日志太多，占用了全部的硬盤剩余空間導(dǎo)致的，通過簡(jiǎn)單刪除日志或加大存儲(chǔ)空間就能夠解決。但是我在Oracle 10g上發(fā)現(xiàn)，存儲(chǔ)空間還有很大，卻也報(bào)這個(gè)錯(cuò)誤。原來是Oracle 10g中新的特性，對(duì)Flash Recovery的管理導(dǎo)致的。

1、軟硬件環(huán)境

服務(wù)器HP Proliant DL580G4(Intel Xeon 3.16GHz/4GB/ 72.8*4/RAID4)

操作系統(tǒng)Red Flag DC Server release 5.0 (Trinity) for x86-64 Linux

數(shù)據(jù)庫(kù)Oracle 10.2.0.1.0

2、問題現(xiàn)象

數(shù)據(jù)庫(kù)系統(tǒng)已經(jīng)試運(yùn)行了半個(gè)多月，在7月24日晚上連接數(shù)據(jù)庫(kù)后做數(shù)據(jù)更新時(shí)出現(xiàn)ORA-00257錯(cuò)誤，如下圖。

提示歸檔錯(cuò)誤，通過查找ORACLE錯(cuò)誤代碼，解釋為硬盤空間不足，需要?jiǎng)h除歸檔日志增加空間，但是服務(wù)器可用空間200GB，目前只用了10GB左右，這是為什么呢？

3、診斷過程：

(1)查看ORACLE數(shù)據(jù)庫(kù)歸檔日志情況

[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

說明在出現(xiàn)問題之前數(shù)據(jù)庫(kù)歸檔處理一直是正常的。

(2)查看數(shù)據(jù)庫(kù)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

發(fā)現(xiàn)ARC狀態(tài)為NO，表示系統(tǒng)沒法自動(dòng)做歸檔。

(3)手工切換日志

SQL> alter system switch logfile;

alter system switch logfile

*

第1行出現(xiàn)錯(cuò)誤:

ORA-01013: 用戶請(qǐng)求取消當(dāng)前的操作

在等待長(zhǎng)時(shí)間沒反應(yīng)后，中斷操作，手工切換日志沒有成功。

(4)查看Oracle數(shù)據(jù)庫(kù)后臺(tái)歸檔服務(wù)進(jìn)程

[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 ~]$

后臺(tái)進(jìn)程都正常運(yùn)行。

(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行。

發(fā)現(xiàn)ARCHIVELOG占近70％，BACKUPPIRCR占了30％，這樣FLASH_RECOVERY_AREA空間的空間已經(jīng)被完全占據(jù)了。

4、解決過程

根據(jù)數(shù)據(jù)庫(kù)目前可用存儲(chǔ)空間為200GB、FLASH_RECOVERY_AREA空間為2GB的實(shí)際情況，把FLASH_RECOVERY_AREA的空間修改為20GB。

SQL> alter system set DB_RECOVERY_FILE_DEST_SIZE=20g;

系統(tǒng)已更改。

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

這時(shí)再查看日志的狀態(tài)，發(fā)現(xiàn)REDO LOG處于正常的歸檔狀態(tài)。

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>

總結(jié)

造成本次故障的原因由兩方面同時(shí)發(fā)生所造成的：

·其一是Flash_Recovery_Area空間缺省安裝時(shí)比較小，只有2GB，容易用完；

·其二是由于采用歸檔方式通過Veritas備份，由于備份軟件沒有運(yùn)行，造成歸檔日志沒有及時(shí)刪除。

從本次故障解決處理中，我們可以得出經(jīng)驗(yàn)教訓(xùn)：

·Oracle 10g數(shù)據(jù)庫(kù)物理空間管理方式與以前Oracle發(fā)生了變化，對(duì)歸檔日志所在的Flash_Recovery_Area空間進(jìn)行了另外限制；

·對(duì)數(shù)據(jù)庫(kù)系統(tǒng)管理員要對(duì)Oracle數(shù)據(jù)庫(kù)歸檔日志、備份軟件運(yùn)行狀況定期檢查，提前發(fā)現(xiàn)、處理可能發(fā)生的故障。

總結(jié)

以上是生活随笔為你收集整理的ora257 linux,ORA-00257解决的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。