轉至：https://www.jianshu.com/p/d098e48b02e2
歸檔日志archivelog：
- 可以配置單個日志文件的大小（oracle安裝時設置或安裝后修改配置）；
- 可以配置日志文件占用的（總）空間大小。
日志文件產生的多少，主要取決於數據庫中數據變化的頻率。
一般配置項如下：
--以dba角色登錄
conn / as sysdba
--（建議）重新指定歸檔日志存儲目錄，需注意目錄一定要先建好，linux下操作系統的oracle用戶要有權限訪問此目錄
alter system set log_archive_dest_1='location=D:\archivelog' scope=spfile;
alter system set log_archive_start=TRUE scope=spfile;
--定義日志文件的命名格式
alter system set log_archive_format='arch%t_%s_%r.arc' scope=spfile;
--修改日志文件占用的（總）空間大小
（建議）alter system set db_recovery_file_dest_size= 40G;（與日志刪除頻率配合，查看此參數：show parameter db_recovery_file_dest_size）
--重新掛載后生效
shutdown immediate;
startup mount;
alter database archivelog;
alter database open;
1.Oracle重啟的時候提示這個錯，原因是因為閃回歸檔區的空間滿了
ORA-03113: end-of-file on communication channel Process ID: 14263 Session ID: 335 Serial number: 5
直接startup是起不來的
下面是出錯到解決的全過程：
sqlplus / as sysdba，進入數據庫 startup mount;啟動mount狀態 alter database mount; alter database open; 報如下錯誤： * ERROR at line 1: ORA-03113: end-of-file on communication channel Process ID: 252 Session ID: 1 Serial number: 3 到這一個步驟，就停下來。
nomount 狀態 數據庫獲取spfile的配置來啟動數據庫，其實這個時候可以通過 show parameter，查看 background_dump_dest 這個參數 來了解alter 文件到底存放在那里了。
mount 狀態，數據庫實例已經獲取了控制文件.控制文件里面有數據文件的指針，等等很多信息。
background_dump_dest /u01/app/oracle/fast_recovery_area
然后查看這個日志：(/u01/app是安裝路徑)
/u01/app/oracle/diag/rdbms/orcl/orcl/trace/alert_orcl.log
最后有這兩句
Errors in file /u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_arc1_7251.trc: ORA-19815: WARNING: db_recovery_file_dest_size of 4385144832 bytes is 100.00% used, and has 0 remaining bytes available.
查看這個文件，查看錯誤信息：(上面日志里記錄的)
/u01/app/oracle/diag/rdbms/orcl/orcl/trace/orcl_arc1_7251.trc
ORA-19815:這一行提示了db_recovery_file_dest_size使用100%，閃回歸檔區滿了
/u01/app/oracle/fast_recovery_area //是存檔日志存放目錄
現在做的操作是刪除存檔日志或者增大閃回恢復區(當然還有別的方法)
我的處理方法是增大閃回恢復區,下邊是我的操作過程：
(確定數據庫是關閉的或者修改完重啟數據庫 ) #SQL> show parameter recover SQL> show parameter db_recovery_file_dest_size; NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ db_recovery_file_dest_size big integer 2G SQL> alter system set db_recovery_file_dest_size=10G scope=spfile; 系統已更改。 SQL> alter database open; 數據庫已更改。 SQL> show parameter db_recovery_file_dest_size; NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ db_recovery_file_dest_size big integer 3G SQL>alter database open noresetlogs; Database altered. //提示這個就好
然后查看數據庫狀態
select open_mode from v$database;
顯示READ WRITE就OK了。
2.客戶使用過程中不能登錄業務系統，經檢查后發現后台日志報錯
ORA-00257: archiver error. Connect internal only, until freed.
該錯誤是由於歸檔日志滿了，造成的。
查看了下V$FLASH_RECOVERY_AREA_USAGE，看看歸檔目錄使用的情況。果然是歸檔滿了。
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 99.9 0 255 BACKUPPIECE 0 0 0 IMAGECOPY 0 0 0 FLASHBACKLOG 0 0 0
注：可以看出，ARCHIVELOG日志已經達到99.9%了。造成歸檔滿的原因是因為有一個用戶在做大量更新操作
同樣是增大閃回恢復區(參考上面第一種錯誤解決方法)
SQL> select * from v$flash_recovery_area_usage; --查看空間占用率 SQL> select * from v$recovery_file_dest; --查看歸檔日志的存放位置; rman清空歸檔日志方式 $ rman RAM> connect target / RAM> crosscheck archivelog all; --查看可以所有的歸檔文件 RAM> delete expired archivelog all; --清空過期的歸檔文件 如何確認歸檔日志是否過期,rman有一個保留策略,可以定義多少天之前的日志算為過期; RAM> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 14 DAYS; 讓恢復窗口成為14天大小。 RAM> show all; --查看所有的rman策略. SQL> select count(*) from v$archived_log where archived='YES' and deleted='NO'; --查看所有歸檔，未刪除的歸檔日志
定時清理歸檔日志
將clear_arc.sh加入定時任務
#crontab -l 00 00 * * * clear_arc.sh #clear_arc.sh rman target / nocatalog cmdfile clear.rcv #clear.rcv DELETE ARCHIVELOG ALL COMPLETED BEFORE 'SYSDATE-7'; crosscheck archivelog all; delete expired archivelog all;