ORA-00257archiver error解決辦法

1.之前有處理單機過oracle 11.2.0.4歸檔日誌磁盤空間不足的問題 ，但是沒有處理過ORACLE RAC的歸檔日誌磁盤空間不足的問題

所以沒有預想到會是出現asm磁盤空間不足的議題

Oracle數據庫是目前業界最常用的大型數據庫系統，我在單機ORACLE的實際項目中有遇到出現ORA-00257錯誤（空間不足錯誤），

通過查找資料，發現絕大部分說這是由於歸檔日誌太多，占用了全部的硬盤剩余空間導致的，可通過簡單刪除日誌或加大存儲空間就能夠解決。但是我在Oracle11g RAC上兩個RAC節點發現，它們的存儲空間都還有很大，卻也報這個錯誤，經過大半天的折騰，發現原來是Oracle11g RAC中的ASM磁盤空間不足導致的。

操作系統CentOS 6.5 x86-64Linux

數據庫Oracle 11.2.0.4.0

2.問題現象

數據庫系統已經運行了一年多，在5月8號開發同事用應用賬號連接數據庫後，發現無法連接登入，並且出現ORA-00257：archive error.connect internal only,until freed 錯誤。

提示歸檔錯誤，通過查找ORACLE錯誤代碼，解釋為硬盤空間不足，需要刪除歸檔日誌增加空間，但是服務器兩個節點可用空間都還有1.4T，目前只用了10GB左右，這是為什麽呢？

且在5月8號用rman形式刪除清理系統100天以前的歸檔日誌以後好了，沒想到第二天5月9號又出現了。沒有理由啊，一天的歸檔日誌大過一百天的歸檔日誌，所以我就質疑數據庫報錯的準確性，認為這只是表面的歸檔日誌空間已滿，實質性的問題卻還不知道。

3.診斷過程：

因為數據庫不是我架設的，對oracle也不太熟，所以不知道歸檔日誌放置的路徑，通過語句查找也得到的是個+ARC/back/archivelog/**之類的，但是我就是想破腦袋，用find的方式也找不到具體存放路徑。

a.查看數據庫REDOLOG情況

[root@~]$ sqlplus / as sysdba

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 9-5月 -17

2 1 99 52428800 1 NO INACTIVE 3600145 9-5月 -17

3 1 100 52428800 1 NO INACTIVE 3611932 9-5月 -17

發現ARC狀態為NO，表示系統沒法自動做歸檔。

b.查看Oracle數據庫後臺歸檔服務進程

[oracle@~ ]ps -ef | grep oracle

發現grid 3081 1 0 10:14 ? 00:00:00 oracle+ASM1 (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))

一個節點如上述服務正常，但另外一個節點卻LOCAL=NO的類似情況，反正服務不正常

c.查看FLASH_RECOVERY_AREA空間中各部分使用情況

SQL> select * from v$recovery_file_dest;

NAME

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

SPACE_LIMIT SPACE_USED SPACE_RECLAIMABLE NUMBER_OF_FILES

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

+BACKUP

1.2885E+11 484442112 0 5

##註：空間大把的有

SQL> select * from v$flash_recovery_area_usage;

FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE

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

NUMBER_OF_FILES

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

CONTROL FILE .04 0 1

REDO LOG .33 0 4

ARCHIVED LOG 0 0 0

FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE

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

NUMBER_OF_FILES

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

BACKUP PIECE 0 0 0

IMAGE COPY 0 0 0

FLASHBACK LOG 0 0 0

FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE

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

NUMBER_OF_FILES

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

FOREIGN ARCHIVED LOG 0 0 0

7 rows selected.

發現ARCHIVELOG、BACKUPPIRCR都不大，就是0，沒什麽占用率，這樣FLASH_RECOVERY_AREA空間的空間還大把的有。

因為之前報錯時，不知道如何處理問題，就像直接shutdown immediate一個節點看看，沒想到半天沒任何反應，就直接使用shutdown abort強行關閉,該節點出現下列節點掛載實例報問題

d.故障節點掛載實例報錯：

SQL> startup

ORACLE instance started.

Total System Global Area 413372416 bytes

Fixed Size 2253784 bytes

Variable Size 327158824 bytes

Database Buffers 79691776 bytes

Redo Buffers 4268032 bytes

Database mounted.

ORA-03113: end-of-file on communication channel

Process ID: 2420

Session ID: 1 Serial number: 5

e.查找資料發現，下面做法可行：

SQL> conn / as sysdba

Connected to an idle instance.

SQL> startup nomount

ORACLE instance started.

Total System Global Area 413372416 bytes

Fixed Size 2253784 bytes

Variable Size 327158824 bytes

Database Buffers 79691776 bytes

Redo Buffers 4268032 bytes

SQL> alter database mount;

Database altered.

SQL> alter database open;

alter database open

*

ERROR at line 1:

ORA-01034: ORACLE not available

Process ID: 0

Session ID: 0 Serial number: 0

發現在打開數據文件報錯

SQL> recover database until time ‘2017-05-09‘

ORA-00283: recovery session canceled due to errors

ORA-01124: cannot recover data file 1 - file is in use or recovery

ORA-01110: data file 1: ‘+DATADG/fmall/datafile/system.259.907327891‘

用覆蓋形式恢復也報錯

f.後面有資料提出可使用RMAN操作系統刪掉歸檔來解決問題

rman下crosscheck然後delete。

[oracle@~ ]rman target sys/pass

RMAN > crosscheck archivelog all;

validation succeeded for archived log

archived log file name=+ARCH/fmall/archivelog/2017_03_08/thread_2_seq_6362.21528.938070989 RECID=43022 STAMP=938070990

validation succeeded for archived log

RMAN-06900: WARNING: unable to generate V$RMAN_STATUS or V$RMAN_OUTPUT row

RMAN-06901: WARNING: disabling update of the V$RMAN_STATUS and V$RMAN_OUTPUT rows

ORACLE error from target database:

ORA-01089: immediate shutdown in progress - no operations are permitted

Process ID: 14578

Session ID: 235 Serial number: 2647

校驗日誌的可用性，報錯或者等待很久沒有結果出來

RMAN > delete archivelog all completed before ‘sysdate-30‘;

RMAN-08137: WARNING: archived log not deleted, needed for standby or upstream capture process

如果你刪除三十天前的歸檔日誌，等待很久卻沒有結果，甚至像上面一樣報錯可以參考我下面的做法

RMAN > delete force noprompt archivelog until time ‘sysdate-30‘;

強制性刪除三十天前的歸檔日誌

網站異常告警解除，說明歸檔日誌騰出空間，致使數據庫可正常提供應用連接。

g.實例證明，歸檔日誌空間已滿導致應用無法連接數據庫

有經驗的DBA告訴我說，RAC會有一個ASM的磁盤空間議題，我經過查詢ASM磁盤空間發現，我的媽呀，ARCH的空間就才騰出282M。

SQL> select name,total_mb,free_mb from v$asm_disk;

NAME TOTAL_MB FREE_MB

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

GRIDDG_0001 4768 4585

ARCH_0000 944137 282

DATADG_0000 1238390 1202771

GRIDDG_0000 4768 4553

BACKUP_0000 953675 949001

再次進入RMAN，使用delete archivelog的方式再刪除15天後，查看ASM磁盤空間大小：

SQL> select name,total_mb,free_mb from v$asm_disk;

NAME TOTAL_MB FREE_MB

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

GRIDDG_0001 4768 4585

ARCH_0000 944137 716045

DATADG_0000 1238390 1202771

GRIDDG_0000 4768 4553

BACKUP_0000 953675 949001

空出了將近700多G的空間，太可怕了，短短十五天就能夠用掉將近七百多G的歸檔日誌空間，我的數據庫大小才1.1G，歸檔日誌就一天以十幾二十G的速度瘋長。一定是哪裏出了問題，必須徹查。

當然首先要做的估計就是把清理歸檔日誌命令寫成腳本納入crontab裏，按一定時間進行處理。初步懷疑是應用程式sql語句中存在類似於死循環的東西，導致歸檔日誌如此龐大，後續有什麽發現，我將再次記錄下來。

致此，歸檔日誌空間已滿議題是暫時解決了。

本文出自 “10793382” 博客，請務必保留此出處http://10803382.blog.51cto.com/10793382/1924973

ORACLE 11G DB RAC ORA-00257archiver error解決辦法