群友問題--近期每秒頻繁產生40m歸檔日誌檔案

網友問題

資料庫為Oracle 10，昨天開始oracle\product\10.2.0\flash_recovery_area\ORCL\ARCHIVELOG\
下當天內的日誌每秒增加一個40M的檔案，檔名為O1_MF_1_1316_C5F3GRL2_.ARC，我想看看裡面到底是記錄的什麼，是什麼操作導致，但是查詢網上辦法都不可行，請教大神
問題連結：
http://www.itpub.net/thread-1943626-1-1.html

結論

1,線上日誌檔案大小與歸檔日誌檔案大小不同，歸檔日誌檔案大小正常情況下稍小於線上日誌檔案
我理解歸檔日誌檔案大小取決於當前資料庫的事務的產生量
2，沒有找到控制日誌檔案切換的引數
3，經繼續分析，此時就會有2種分支
A，如果在某個特定時間內頻繁產生歸檔日誌檔案，且新增的歸檔日誌檔案稍小於線上日誌檔案，可以在AWR檢視LOAD PROFILE中的REDO SIZE及TRASANCTION
也就是這樣頻增歸檔日誌檔案是正常的，是因為業務量上去了，事務增加或有新的大事務產生
B，如果頻繁產生的日誌檔案極小，就可能是BUG了，可以在MOS去排查，結合資料庫版本，歸檔檔案大小
4，也可以到ALERT進行檢視，也會有對應的資訊
5，一定要深入理解AWR，裡面知識點眾多，要繼續深入學習ORACLE概念，比如：何時歸檔，歸檔程式的概念及優化；線上日誌實際佔用空間以及分配空間的關係

思路演進

測試

--- oracle version
SQL> select * from v$version where rownum=1;

BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 - 64bi

---archive info
SQL> archive log list
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /11204rdbms/test
Oldest online log sequence 238
Next log sequence to archive 240
Current log sequence 240

SQL> select group#,sequence#,bytes/1024/1024 mb,status from v$log;

GROUP# SEQUENCE# MB STATUS
---------- ---------- ---------- ----------------
1 238 50 INACTIVE
2 239 50 INACTIVE
3 240 50 CURRENT

--可見產生的歸檔檔案大小不定，皆小於線上重作日誌檔案大小
SQL> select group#,sequence#,bytes/1024/1024 mb,status from v$log;

GROUP# SEQUENCE# MB STATUS
---------- ---------- ---------- ----------------
1 244 50 INACTIVE
2 245 50 ACTIVE
3 246 50 CURRENT

206 /11204rdbms/test/1_206_863224512.dbf 206 48.9902344
207 /11204rdbms/test/1_207_863224512.dbf 207 48.9902344
208 /11204rdbms/test/1_209_863224512.dbf 209 48.9902344

RECID NAME SEQUENCE# MB
---------- -------------------------------------------------- ---------- ----------
209 /11204rdbms/test/1_208_863224512.dbf 208 48.9902344
210 /11204rdbms/test/1_210_863224512.dbf 210 48.9902344
211 /11204rdbms/test/1_211_863224512.dbf 211 48.9902344
中間內容略
244 /11204rdbms/test/1_244_863224512.dbf 244 34.4448242
245 /11204rdbms/test/1_245_863224512.dbf 245 34.4448242

70 rows selected.

SQL>

SQL> insert into t_redo select level,level from dual connect by level<=1000000;

1000000 rows created.

SQL> insert into t_redo select level,level from dual connect by level<=1000000;

1000000 rows created.

可見每次產生的歸檔日誌檔案大小一定
SQL> select group#,sequence#,bytes/1024/1024 mb,status from v$log;

GROUP# SEQUENCE# MB STATUS
---------- ---------- ---------- ----------------
1 247 50 CURRENT
2 245 50 INACTIVE
3 246 50 ACTIVE

SQL> select recid,name,sequence#,blocks*block_size/1024/1024 as mb from v$archived_log where recid>=244;

RECID NAME SEQUENCE# MB
---------- -------------------------------------------------- ---------- ----------
244 /11204rdbms/test/1_244_863224512.dbf 244 34.4448242
245 /11204rdbms/test/1_245_863224512.dbf 245 34.4448242
246 /11204rdbms/test/1_246_863224512.dbf 246 34.4438477

--沒查到相關的引數控制多次頻率產生歸檔日誌檔案
set linesize 300
col name_1 for a50
col value_1 for a50
col desc1 for a50

select
ksppinm as name_1,
ksppstvl as value_1,
ksppdesc as desc1
from x$ksppi x, x$ksppcv y
where (x.indx = y.indx) and lower(x.ksppinm) like '%&parameter%';

---分析歸檔日誌檔案，看到底裡面是儲存什麼型別的操作，從而進行鍼對性的分析與處理

http://blog.itpub.net/9240380/viewspace-745386/

---經進一步分析，及查閱資料，可以對比檢視異常時間點的AWR，主要檢視LOAD PROFILE中的REDO SIZE及TRANSACTION
1,REDO SIZE是不是比正常時間點增加很多，然後可以繼續檢視TOP SQL中的PHYSICAL READ
2，如果TRANSACTION不是很高，但是REDO SIZE卻很高，表明資料庫事務不多，但可能有一些大事務執行，請檢視AWR中的TOP SQL
PHYSICAL READ，同時可以和應用開發人員溝通，是否近期新上線業務模式，調取其對應SQL進行分析

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/9240380/viewspace-1847983/，如需轉載，請註明出處，否則將追究法律責任。

群友問題--近期每秒頻繁產生40m歸檔日誌檔案

網友問題

結論

思路演進

測試

相關文章