由於歸檔路徑設定不當，系統無法響應的問題

由於歸檔路徑設定不當，系統無法響應的問題
Author: Kevin Zou
Date: 2009-2-17

環境： DB 10.2.0.
OS: AIX 5.3
系統採用DBCA的方式來安裝，安裝完畢後沒有更改配置。
一次在做大量資料重新整理操作時，發現新提交到系統的SQL無法響應，整個系統都HANG住。
檢視系統資源,iostat ,topas發現系統只有DISK的資源比較繁忙，其餘都很空閒：
AIX h3cap61 3 5 0059362D4C00 02/18/09

System configuration: lcpu=4 drives=7 mode=Capped

16:19:19 device %busy avque r+w/s Kbs/s avwait avserv

16:19:21     hdisk0      0      0.0        0        3      0.0      0.2
             hdisk5     14      0.0      337     5392      0.0      0.0
             hdisk4      0      0.0        0        0      0.0      0.0
                cd0      0      0.0        0        0      0.0      0.0
             hdisk2      0      0.0        0        0      0.0      0.0
             hdisk3      0      0.0        0        0      0.0      0.0
             hdisk1      0      0.0        0        1      0.0     10.5

16:19:23     hdisk0      0      0.0        0        3      0.0      0.2
             hdisk5     15      0.0      358     5740      0.0      0.0
             hdisk4      0      0.0        0        0      0.0      0.0
                cd0      0      0.0        0        0      0.0      0.0
             hdisk2      0      0.0        0        0      0.0      0.0
             hdisk3      0      0.0        0        0      0.0      0.0
             hdisk1      0      0.0        0        0      0.0      0.0

Average      hdisk0      0      0.0        0        3      0.0      0.2
             hdisk5     14      0.0      347     5566      0.0      0.0
             hdisk4      0      0.0        0        0      0.0      0.0
                cd0      0      0.0        0        0      0.0      0.0
             hdisk2      0      0.0        0        0      0.0      0.0
             hdisk3      0      0.0        0        0      0.0      0.0
             hdisk1      0      0.0        0        0      0.0      5.3
檢視等待事件：
SID EVENT
---------- ----------------------------------------------------------------
       128 library cache lock
       129 library cache lock
       130 switch logfile command
       131 library cache lock
       132 buffer busy waits
       134 log file switch (checkpoint incomplete)
       135 log file switch (checkpoint incomplete)
       140 Streams AQ: qmn slave idle wait
       142 log file switch (checkpoint incomplete)
       146 log file switch (checkpoint incomplete)
       149 Streams AQ: qmn coordinator idle wait

       SID EVENT
---------- ----------------------------------------------------------------
       150 log file switch (checkpoint incomplete)
       154 class slave wait
       156 ASM background timer
       159 log file switch (checkpoint incomplete)
       161 log file switch (checkpoint incomplete)
       164 buffer busy waits
       170 pmon timer
系統有大量的log file switch 的等待事件。
難道是歸檔目錄滿的原因導致系統無法進行新的事物：
SQL> archive log list
Database log mode              Archive Mode
Automatic archival             Enabled
Archive destination            USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence     113
Next log sequence to archive   113
Current log sequence           115
SQL> show parameter USE_DB_RECOVERY_FILE_DEST

這裡Archive destination 啟用了新的引數USE_DB_RECOVERY_FILE_DEST 。在9i沒有使用過，當時沒有仔細去思考，而是把目光注意到library cache lock 的等待事件。
查詢之後，發現library cache lock這些等待事件對應的session也沒有執行任何的sql。
通過檢視最耗cpu資源的程式，發現都是歸檔程式。
# ps -ef|grep 438720
    root 315398 496036   0 16:31:33 pts/4 0:00 grep 438720
oracle 438720      1   2   Feb 13      - 0:54 ora_arc1_kong
# ps -ef|grep 229542
oracle 229542      1   1   Feb 13      - 0:58 ora_arc0_kong
    root 401408 496036   0 16:31:43 pts/4 0:00 grep 229542

最後還是把目光轉移到了歸檔程式上。想到剛開始出現的“陌生”引數：USE_DB_RECOVERY_FILE_DEST
找到了說明，原來是需要看db_recovery_file_dest 引數，而不是USE_DB_RECOVERY_FILE_DEST。NND!!
檢視其配置：
SQL> show parameter db_recovery_file_dest

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest                string      /oracle/product/flash_recovery
                                                 _area
db_recovery_file_dest_size           big integer 2G
在OS上檢視其空間餘額：
/oracle/product/flash_recovery_area/KONG
$ cd ..
$ du -sg .
2.00    .

設定為其他目錄，再次執行日誌切換：
1* alter system switch logfile
SQL> /

System altered.
一切都正常了。
檢視等待事件
SID EVENT
---------- ----------------------------------------------------------------
       132 jobq slave wait
       140 Streams AQ: qmn slave idle wait
       142 Streams AQ: waiting for time management or cleanup tasks
       149 Streams AQ: qmn coordinator idle wait
       154 class slave wait
       156 ASM background timer
       164 smon timer
       170 pmon timer
都是非重點關注的物件了。

在alert檔案也有歸檔空間滿的報錯資訊：
ARC0: Failed to archive thread 1 sequence 113 (19809)
Wed Feb 18 16:38:00 2009
Errors in file /oracle/product/admin/kong/bdump/kong_arc1_438720.trc:
ORA-19815: WARNING: db_recovery_file_dest_size of 2147483648 bytes is 100.00% used, and has 0 remaining bytes available.
Wed Feb 18 16:38:00 2009
************************************************************************
You have following choices to free up space from flash recovery area:
1. Consider changing RMAN RETENTION POLICY. If you are using Data Guard,
   then consider changing RMAN ARCHIVELOG DELETION POLICY.
2. Back up files to tertiary device such as tape using RMAN
   BACKUP RECOVERY AREA command.
3. Add disk space and increase db_recovery_file_dest_size parameter to
   reflect the new space.
4. Delete unnecessary files using RMAN DELETE command. If an operating
   system command was used to delete files, then use RMAN CROSSCHECK and
   DELETE EXPIRED commands.

再次證明alert日誌很重要，有事沒事拜讀ALERT！！
不熟悉10g的特性，虛驚一場！
謝謝ITPUB上棉花的幫助

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

由於歸檔路徑設定不當，系統無法響應的問題

相關文章