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

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語句中存在類似于死循環的東西，導致歸檔日志如此龐大，后續有什么發現，我將再次記錄下來。

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