群友問題--近期每秒頻繁產生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進行分析