Oracle歸檔日志是Oracle數(shù)據(jù)庫的重要功能，用于將數(shù)據(jù)庫的重做日志文件（Redo Log）保存到歸檔日志文件（Archive Log）中。歸檔日志的作用是提供數(shù)據(jù)庫的備份和恢復(fù)功能，以及支持數(shù)據(jù)庫的持續(xù)性和數(shù)據(jù)完整性。
當數(shù)據(jù)庫處于歸檔模式時，數(shù)據(jù)庫引擎會將已經(jīng)寫滿的重做日志文件保存到歸檔日志文件中，而不是覆蓋已有的重做日志。這樣可以確保數(shù)據(jù)庫的完整性，并且可以使用歸檔日志文件進行數(shù)據(jù)庫的恢復(fù)操作。
歸檔日志對于數(shù)據(jù)庫的備份和恢復(fù)非常重要。通過定期備份歸檔日志文件，可以保證數(shù)據(jù)庫在發(fā)生故障時能夠進行恢復(fù)。同時，歸檔日志還允許將數(shù)據(jù)庫恢復(fù)到特定的時間點，以滿足特定業(yè)務(wù)需求。

基礎(chǔ)操作

在Oracle數(shù)據(jù)庫中，可以通過以下步驟來設(shè)置和查看歸檔日志空間：

1. 首先，確認數(shù)據(jù)庫是否處于歸檔模式?？梢酝ㄟ^以下SQL語句查詢：

SQL> SELECT log_mode FROM v$database;
LOG_MODEARCHIVELOG

如果log_mode的值為ARCHIVELOG，則數(shù)據(jù)庫處于歸檔模式；如果值為NOARCHIVELOG，則數(shù)據(jù)庫未啟用歸檔模式。

2. 如果數(shù)據(jù)庫未啟用歸檔模式，可以通過以下SQL語句將其切換到歸檔模式：
   修改歸檔模式的操作只能在 mount 狀態(tài)下進行，不能處于 open 狀態(tài)

SQL> shutdown immediate
數(shù)據(jù)庫已經(jīng)關(guān)閉。
已經(jīng)卸載數(shù)據(jù)庫。
ORACLE 例程已經(jīng)關(guān)閉。
SQL> startup mount
ORACLE 例程已經(jīng)啟動。
Total System Global Area 3290345472 bytes
Fixed Size                  2180224 bytes
Variable Size            2382367616 bytes
Database Buffers          889192448 bytes
Redo Buffers               16605184 bytes
數(shù)據(jù)庫裝載完畢。
SQL> alter database archivelog;
數(shù)據(jù)庫已更改。
SQL> alter database open;
數(shù)據(jù)庫已更改。

3. 確認數(shù)據(jù)庫已切換到歸檔模式后，可以設(shè)置歸檔日志空間的大小?？梢酝ㄟ^以下SQL語句設(shè)置歸檔日志空間的大小為50MB（根據(jù)需求進行調(diào)整）：
   52428800 = 50 * 1024 * 1024

SQL> alter system set db_recovery_file_dest_size=  52428800;
系統(tǒng)已更改。

4. 使用以下SQL語句查詢當前歸檔日志空間的使用情況：

select name,space_limit / 1024 / 1024 / 1024 || 'GB' as 空間限制,space_used / 1024 / 1024 / 1024 || 'GB' 已使用from v$recovery_file_dest

這將顯示歸檔日志目標的名稱、空間限制和已使用的空間。

問題發(fā)生

下面進入對一次因歸檔日志空間占滿，導(dǎo)致系統(tǒng)停止服務(wù)的故障在某個陽光明媚的周末發(fā)生后的處理過程。

1. 系統(tǒng)停止響應(yīng)，數(shù)據(jù)庫登錄有以下提示：

ORA-00257:archiver error. Connect internal only,until freed

2. 很明顯，歸檔日志滿了，立即刪除歸檔日志，保留最近3天。

rman
RMAN> connect target 用戶名/密碼;
連接到目標數(shù)據(jù)庫: ORCL (DBID=1616110362)
RMAN> delete archivelog until time 'sysdate-3';

3. 問題未解決，查看歸檔空間占用情況。

select name,space_limit / 1024 / 1024 / 1024 || 'GB' as 空間限制,space_used / 1024 / 1024 / 1024 || 'GB' 已使用from v$recovery_file_dest

4. 發(fā)現(xiàn)占用空間未釋放，接著刪除所有歸檔：

RMAN> delete archivelog all;

5. 系統(tǒng)恢復(fù)。過了幾個小時，問題再次發(fā)生。
6. 再次刪除所有歸檔日志，系統(tǒng)恢復(fù)，開始排查問題原因。

排查過程

1. 按天統(tǒng)計

select to_char(COMPLETION_TIME, 'yyyymmdd'), count(*)from v$archived_log twhere COMPLETION_TIME > sysdate - 7group by to_char(COMPLETION_TIME, 'yyyymmdd')order by to_char(COMPLETION_TIME, 'yyyymmdd');

這是一個查詢語句，用于查詢過去7天內(nèi)完成的歸檔日志數(shù)量，并按照日期進行分組和排序。
發(fā)現(xiàn)前6天正常，當天歸檔日志異常增長。
2. 按小時統(tǒng)計

select to_char(FIRST_TIME, 'yyyymmddhh24'), count(*)from sys.v_$archived_log twhere t.FIRST_TIME > trunc(sysdate)group by to_char(FIRST_TIME, 'yyyymmddhh24')order by to_char(FIRST_TIME, 'yyyymmddhh24')

該SQL用于查詢當天開始的歸檔日志數(shù)量，并按照小時進行分組和排序。
3. 按天和小時綜合統(tǒng)計

SELECT    TO_CHAR(FIRST_TIME,'YYYY-MM-DD') DAY,TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'00',1,0)),'999') "00",TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'01',1,0)),'999') "01",TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'02',1,0)),'999') "02",TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'03',1,0)),'999') "03",TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'04',1,0)),'999') "04",TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'05',1,0)),'999') "05",TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'06',1,0)),'999') "06",TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'07',1,0)),'999') "07",TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'08',1,0)),'999') "08",TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'09',1,0)),'999') "09",TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'10',1,0)),'999') "10",TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'11',1,0)),'999') "11",TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'12',1,0)),'999') "12",TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'13',1,0)),'999') "13",TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'14',1,0)),'999') "14",TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'15',1,0)),'999') "15",TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'16',1,0)),'999') "16",TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'17',1,0)),'999') "17",TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'18',1,0)),'999') "18",TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'19',1,0)),'999') "19",TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'20',1,0)),'999') "20",TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'21',1,0)),'999') "21",TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'22',1,0)),'999') "22",TO_CHAR(SUM(DECODE(TO_CHAR(FIRST_TIME,'HH24'),'23',1,0)),'999') "23"
FROM V$LOG_HISTORY
GROUP BY TO_CHAR(FIRST_TIME,'YYYY-MM-DD') 
ORDER BY 1 DESC;

此SQL語句，用于統(tǒng)計每天每個小時的日志數(shù)量，并按照日期倒序排序
3. 根據(jù)按小時統(tǒng)計分析，發(fā)現(xiàn)歸檔日志集中在當天2個時間段，其他時間段基本正常。懷疑是在相關(guān)時間自動執(zhí)行的后臺任務(wù)造成，經(jīng)深入排查予以否認。
4. AWR報告生成

sqlplus /nolog
conn / as sysdba
@?/rdbms/admin/awrrpt.sql

報告生成失敗，原因是沒有快照（Snap）
5. 分析沒有快照（Snap）原因，網(wǎng)上說一般是SYSAUX表空間不足造成的，查詢表空間占用情況，果然滿了
6. 清理表空間

select distinct 'truncate table ' || segment_name || ';',s.bytes / 1024 / 1024 MBfrom dba_segments swhere s.segment_name like 'WRH$%'and segment_type in ('TABLE PARTITION', 'TABLE')and s.bytes / 1024 / 1024 > 100order by s.bytes / 1024 / 1024 desc;

此SQL可生成清理以 ‘WRH$’ 開頭的、大于100MB的表的SQL。生成后執(zhí)行，完成表空間清理。

7. 問題解決，真是陰差陽錯。

猜測的原因：
因SYSAUX表空間滿，造成連鎖反應(yīng)，表現(xiàn)為歸檔日志異常增長。

一般情況分析

歸檔日志增長一般是DML操作大量數(shù)據(jù)造成的，而由SYSAUX表空間滿的原因所造成的則比較少見，故記之。

排查歸檔日志暴增的方法，一般包括以下三個手段：

1. SQL語句
2. AWR
3. 挖掘歸檔日志

---

本文到此結(jié)束，感謝您的觀看！！！