Oracle資料庫的ORA-00257故障解決過程(轉載）

在導入一個2g的備份檔案時，資料庫報ora-00257故障，找到這篇文章。轉自http://dev.yesky.com/438/2525938.shtml

<b>概述</b>：

<b>1、軟硬體環境</b>

作業系統red flag dc server release 5.0 (trinity) for x86-64 linux

資料庫oracle 10.2.0.1.0

<b>2、問題現象</b>

資料庫系統已經試運作了半個多月，在7月24日晚上連接配接資料庫後做資料更新時出現ora-00257錯誤，如下圖。

提示歸檔錯誤，通過查找oracle錯誤代碼，解釋為硬碟空間不足，需要删除歸檔日志增加空間，但是伺服器可用空間200gb，目前隻用了10gb左右，這是為什麼呢？

<b>3、診斷過程</b>：

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&gt; connect / as sysdba

已連接配接。

sql&gt; 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&gt; 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&gt; 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&gt; 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空間的空間已經被完全占據了。

<b>4、解決過程</b>

根據資料庫目前可用存儲空間為200gb、flash_recovery_area空間為2gb的實際情況，把flash_recovery_area的空間修改為20gb。

sql&gt; alter system set db_recovery_file_dest_size=20g;

系統已更改。

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

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

/oracle/flash_recovery_area 2.1475e+10 2264587776 0 38

這時再檢視日志的狀态，發現redo log處于正常的歸檔狀态。

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

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

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

archivelog 7.6 0 43

backuppiece 4.21 0 2

sql&gt;

5、小結

造成本次故障的原因由兩方面同時發生所造成的：

·其一是flash_recovery_area空間預設安裝時比較小，隻有2gb，容易用完；

·其二是由于采用歸檔方式通過veritas備份，由于備份軟體沒有運作，造成歸檔日志沒有及時删除。

從本次故障解決進行中，我們可以得出經驗教訓：

·oracle 10g資料庫實體空間管理方式與以前oracle發生了變化，對歸檔日志所在的flash_recovery_area空間進行了另外限制；

·對資料庫系統管理者要對oracle資料庫歸檔日志、備份軟體運作狀況定期檢查，提前發現、處理可能發生的故障。

文章轉自莊周夢蝶  ，原文釋出時間5.17