日誌的狀態

可以通過v$log檢視來檢視日誌檔案的狀態：

sys@NEI> select group#,status,first_change# from v$log;
    GROUP# STATUS           FIRST_CHANGE#
---------- ---------------- -------------
         1 CURRENT               59719840
         2 INACTIVE              59719832
         3 INACTIVE              59719835

最常見的日誌狀態有4種：
⑴ CURRENT指當前的日誌檔案，該日誌檔案是活動的，當前正在被使用的，在進行崩潰恢復時Current的日誌檔案是必須的。

⑵ ACTIVE日誌是活動的非當前日誌，該日誌可能已經完成歸檔也可能沒有歸檔，活動的日誌檔案在Crash恢復時會被用到。Active狀態意味著，檢查點尚未完成，如果日誌檔案迴圈使用再次到達該檔案，資料庫將處於等待的停頓狀態，此時在alter檔案中，可以看到類似如下記錄：

Thu Jun 18 05:34:42 2009
Thread 1 cannot allocate new log, sequence 4
Checkpoint not complete
  Current log# 3 seq# 3 mem# 0: /home/oracle/app/oracle/oradata/ccdb/redo03.log

當這種問題出現時，可以從資料庫內部通過v$session_wait來觀察，該檢視會顯示資料庫當前哪些Sesssion正處於這種等待。Checkpoint not complete在資料庫中體現為等待事件log file switch（checkpoint incomplete）：

select sid,event,state from v$session_wait;

同時要注意DBWR程式正在執行db file parallel write，日誌檔案必須等待DBWR完成檢查點觸發的寫操作之後才能被覆蓋。如果設定了引數log_checkpoints_to_alter為True的話，還可以在alert檔案中清晰地看到檢查點的增進和完成情況：

Wed Dec 16 17:15:54 2009
Beginning log switch checkpoint up to RBA [0x8f9.2.10], SCN: 59738301
Thread 1 advanced to log sequence 2297
  Current log# 3 seq# 2297 mem# 0: /home/oracle/oradata/ccdb/redo03.log
Beginning log switch checkpoint up to RBA [0x8fa.2.10], SCN: 59738303
Thread 1 advanced to log sequence 2298
  Current log# 1 seq# 2298 mem# 0: /home/oracle/oradata/ccdb/redo01.log
Thread 1 cannot allocate new log, sequence 2299
Checkpoint not complete
  Current log# 1 seq# 2298 mem# 0: /home/oracle/oradata/ccdb/redo01.log
Wed Dec 16 17:15:55 2009
Completed checkpoint up to RBA [0x8fa.2.10], SCN: 59738303
Completed checkpoint up to RBA [0x8f9.2.10], SCN: 59738301
Wed Dec 16 17:15:59 2009
Beginning log switch checkpoint up to RBA [0x8fb.2.10], SCN: 59738307
Thread 1 advanced to log sequence 2299
  Current log# 2 seq# 2299 mem# 0: /home/oracle/oradata/ccdb/redo02.log
Wed Dec 16 17:16:01 2009
Completed checkpoint up to RBA [0x8fb.2.10], SCN: 59738307

通過這些對比和觀察，可以使我們更好地瞭解Oracle的執行機制。

可以對這個問題做一下簡單的分析，Checkpoint incomplete有多種可能原因：

·日誌檔案過小，切換過於頻繁；
·日誌組太少，不能滿足正常事務量的需要；
·日誌檔案所在磁碟I/O存在瓶頸，導致寫出緩慢，阻塞資料庫正常執行；
·由於資料檔案磁碟I/O瓶頸，DBWR寫出過於緩慢；
·由於事務量巨大，DBWR負荷過高，不堪重負。

針對不同的原因，又可以從不同角度著手解決問題：

·適當增加日誌檔案大小；
·適當增加日誌組數；
·使用更快速磁碟儲存日誌檔案（如：採用更高轉速磁碟；使用RAID10而不是RAID5等方式）；
·改善磁碟I/O效能；
·使用多個DBWR程式或使用非同步I/O等。

總之，只要我沒能夠發現資料庫的問題所在，就能夠從各個角度分析問題並尋找恰當的解決方法。需要強調的是，這是一類嚴重的等待，它意味著資料庫不能再產生日誌，所有資料庫修改操作將全部掛起。

⑶ INACTIVE是非活動日誌，該日誌在例項恢復時不再需要，但是在介質恢復時可能會用到。INACTIVE狀態的日誌也可能沒有被歸檔。如果資料庫啟動在歸檔模式，在未完成歸檔之前，日誌檔案也不允許被覆蓋，這時活動程式處於log file switch(archiving needed)等待之中。

日誌是否完成歸檔，可以根據V$LOG.ARCHIVED欄位進行判斷，以下案例日誌檔案ARCHIVED狀態為NO，也就是尚未歸檔：

sys@NEI> archive log list;
Database log mode              Archive Mode
Automatic archival             Enabled
Archive destination            /home/oracle/archivelog2
Oldest online log sequence     2297
Next log sequence to archive   2299
Current log sequence           2299
sys@NEI> select * from v$log;
    GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARCHIVED   STATUS           FIRST_CHANGE# FIRST_TIME
---------- ---------- ---------- ---------- ---------- ---------- ---------------- ------------- ---------------
         1          1       2301  104857600          1 NO         ACTIVE                59739139 16-DEC-09
         2          1       2302  104857600          1 NO         ACTIVE                59739143 16-DEC-09
         3          1       2303  104857600          1 NO         CURRENT               59739145 16-DEC-09

注意此時所有日誌組都沒有完成歸檔，所有DML事務都將掛起，使用者處於log file switch(archiving needed)等待：

select sid,event from v$sesssion_wait;

這種情況需要DBA介入進行緊急處理，否則普通使用者將無法連線：

sys@NEI> conn dbtan/dbtan
ERROR:
ORA-00257: archiver error. Connect internal only, until freed.

這種情況通常是由資料庫異常引起的，可能是因為I/O緩慢，也可能是因為事務量過大，在特殊情況下，有可能是因為日誌損壞。對於本案例就屬於前者，是由作者人為“瘋狂”switch logfile 所至。

⑷ UNUSED 表示該日誌從未被寫入，這類日誌可能是剛被新增到資料庫或者在RESETLOGS之後被重置。被使用之後，該狀態會被改變。

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