問題現象：在維護專案時經常出現系統不能登入，前台提示ora-00257,判斷是資料庫歸檔空間已滿
技術分析：登入到資料庫，檢視歸檔配置
sql> archive log list;
database log mode archive mode
automatic archival enabled
archive destination use_db_recovery_file_dest
檢視具體歸檔目錄
檢視歸檔已占用的空間（select * from v$flash_recovery_area_usage），歸檔空間已經近10g空間。
解決方案：因當時客戶要求緊急，臨時的解決方案是增加歸檔目錄空間，
增加後前台業務可以正常執行。
sql> alter system set db_recovery_file_dest_size=30g scope=both;
1. 檢視備份方案：因客戶方已有專業的備份軟體，每天備份並刪除備份之前的歸檔日誌檔案，所以備份方案不需要修正。
sql> select name,completion_time,status from v$archived_log;
2. 檢查歸檔日誌的增長情況，在網上參考修改查詢語句，查詢最近一周內，資料庫歸檔的頻率
select to_char(first_time, 'mm/dd') day,
sum(decode(to_char(first_time, 'hh24'), '00', 1, 0)) h00,
sum(decode(to_char(first_time, 'hh24'), '01', 1, 0)) h01,
sum(decode(to_char(first_time, 'hh24'), '02', 1, 0)) h02,
sum(decode(to_char(first_time, 'hh24'), '03', 1, 0)) h03,
sum(decode(to_char(first_time, 'hh24'), '04', 1, 0)) h04,
sum(decode(to_char(first_time, 'hh24'), '05', 1, 0)) h05,
sum(decode(to_char(first_time, 'hh24'), '06', 1, 0)) h06,
sum(decode(to_char(first_time, 'hh24'), '07', 1, 0)) h07,
sum(decode(to_char(first_time, 'hh24'), '08', 1, 0)) h08,
sum(decode(to_char(first_time, 'hh24'), '09', 1, 0)) h09,
sum(decode(to_char(first_time, 'hh24'), '10', 1, 0)) h10,
sum(decode(to_char(first_time, 'hh24'), '11', 1, 0)) h11,
sum(decode(to_char(first_time, 'hh24'), '12', 1, 0)) h12,
sum(decode(to_char(first_time, 'hh24'), '13', 1, 0)) h13,
sum(decode(to_char(first_time, 'hh24'), '14', 1, 0)) h14,
sum(decode(to_char(first_time, 'hh24'), '15', 1, 0)) h15,
sum(decode(to_char(first_time, 'hh24'), '16', 1, 0)) h16,
sum(decode(to_char(first_time, 'hh24'), '17', 1, 0)) h17,
sum(decode(to_char(first_time, 'hh24'), '18', 1, 0)) h18,
sum(decode(to_char(first_time, 'hh24'), '19', 1, 0)) h19,
sum(decode(to_char(first_time, 'hh24'), '20', 1, 0)) h20,
sum(decode(to_char(first_time, 'hh24'), '21', 1, 0)) h21,
sum(decode(to_char(first_time, 'hh24'), '22', 1, 0)) h22,
sum(decode(to_char(first_time, 'hh24'), '23', 1, 0)) h23,
count(*) || '(' ||
trim(to_char(sum(blocks * block_size) / 1024 / 1024, '99,999.9')) || 'm)' total
from (select max(blocks) blocks,
max(block_size) block_size,
max(first_time) first_time
from v$archived_log a
where completion_time > sysdate - 7
and dest_id = 1
group by sequence#)
group by to_char(first_time, 'mm/dd'), to_char(first_time, 'yyyy/mm/dd')
order by to_char(first_time, 'yyyy/mm/dd') desc
檢視結果每天峰值切換頻率達到近600次，
檢視資料庫日誌檔案的大小
50 mb 大小。
所以估計峰值歸檔日誌會達到30g，因切換日誌時可能日誌檔案未寫滿，所以db_recovery_file_dest_size引數暫時調整到30g。
總結方案： 對系統日誌歸檔大小要監控，估計相應的所需空間，避免日誌空間滿影響系統執行。
Oracle歸檔日誌總結
1.開啟歸檔日誌 sqlplus as sysdba sql shutdown immediate sql startup mount 開啟控制檔案，不開啟資料檔案 sql alter database archivelog 將資料庫切換為歸檔模式 sql alter database open 將...
MySQL 空間碎片化問題處理
例項磁碟空間近1個月 趨勢明顯，主要是個別日誌表儲存較大且部分表存在空間碎片化的現象。1 通過日常巡檢以及監控發現某例項磁碟空間近1月 趨勢明顯 外鏈轉存失敗,源站可能有防盜煉機制,建議將儲存下來直接上傳 img 9dlp06ur 1606120420027 image.png 2 在詢問業務方是否...
mysql 歸檔日誌 頻繁產生歸檔日誌處理報告
頻繁產生歸檔日誌處理報告 2017年10月27日，客戶資料庫突然間頻繁產生大量歸檔日誌，導致資料庫hang住，影響現場生產！由於oracle歸檔日誌一般由dml語句產生，所以增加太快應該是dml太頻繁。首先查詢以下每小時連線日誌切換頻率的情況 select to char first time,yy...