[20150505]關于alert.log檔案.txt
--alert.log檔案記錄系統報警資訊以及關鍵記錄,對于資料庫的診斷很有幫助.
--我記得以前有過一次經曆使用vim,不小心編輯了alert檔案,導緻後續的日志資訊無法追加到檔案中.
--實際上這個因為編輯儲存後,檔案inode發生了變化.而出現這樣的情況.
1.先來看看10g的情況:
SCOTT@test> @ &r/ver1
PORT_STRING VERSION BANNER
------------------------------ -------------- ----------------------------------------------------------------
x86_64/Linux 2.4.xx 10.2.0.4.0 Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
SCOTT@test> @ &r/spid
SID SERIAL# SPID C50
------------ ------------ ------ --------------------------------------------------
157 7 26687 alter system kill session '157,7' immediate;
$ ls -l /proc/26687/fd | grep -i alert
--無顯示!
SCOTT@test> alter system archive log current ;
System altered.
lr-x------ 1 oracle oinstall 64 2015-05-05 08:13:45 6 -> /u01/app/oracle/admin/test/bdump/alert_test.log
--可以發現在執行alter system archive log current ;後,打開了alert*.log檔案.
# lsof | grep -E 'alert_test.log|PID'
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
oracle 26476 oracle 6w REG 8,3 1497201 37093990 /u01/app/oracle/admin/test/bdump/alert_test.log
oracle 26476 oracle 8w REG 8,3 1497201 37093990 /u01/app/oracle/admin/test/bdump/alert_test.log
oracle 26478 oracle 6w REG 8,3 1497201 37093990 /u01/app/oracle/admin/test/bdump/alert_test.log
oracle 26478 oracle 8w REG 8,3 1497201 37093990 /u01/app/oracle/admin/test/bdump/alert_test.log
oracle 26480 oracle 6w REG 8,3 1497201 37093990 /u01/app/oracle/admin/test/bdump/alert_test.log
oracle 26480 oracle 8w REG 8,3 1497201 37093990 /u01/app/oracle/admin/test/bdump/alert_test.log
oracle 26482 oracle 6w REG 8,3 1497201 37093990 /u01/app/oracle/admin/test/bdump/alert_test.log
oracle 26482 oracle 8w REG 8,3 1497201 37093990 /u01/app/oracle/admin/test/bdump/alert_test.log
oracle 26484 oracle 6w REG 8,3 1497201 37093990 /u01/app/oracle/admin/test/bdump/alert_test.log
oracle 26484 oracle 8w REG 8,3 1497201 37093990 /u01/app/oracle/admin/test/bdump/alert_test.log
...
--如果仔細檢查這個系統程序PID,可以發現大部分是背景程序.
# ps -ef | grep "ora_dbw0_test" | grep -v grep
oracle 26482 1 0 08:04 ? 00:00:00 ora_dbw0_test
--也就是講在資料庫啟動後,alert*.log的檔案句柄就打開了.如果不小心編輯,導緻檔案inode變化,導緻無法追加日志.
--注意mv并不會改變檔案的inode資訊.
--我做一個mv例子:
$ ls -il alert_test.log
37093990 -rw-r----- 1 oracle oinstall 1497201 2015-05-05 08:14:16 alert_test.log
$ mv alert_test.log alert_test.log_xxx
$ ls -il alert_test.log_xxx
37093990 -rw-r----- 1 oracle oinstall 1497201 2015-05-05 08:14:16 alert_test.log_xxx
--可以發現前面的數字37093990是檔案的inode号,沒有變化.
oracle 26476 oracle 6w REG 8,3 1497201 37093990 /u01/app/oracle/admin/test/bdump/alert_test.log_xxx
oracle 26476 oracle 8w REG 8,3 1497201 37093990 /u01/app/oracle/admin/test/bdump/alert_test.log_xxx
oracle 26478 oracle 6w REG 8,3 1497201 37093990 /u01/app/oracle/admin/test/bdump/alert_test.log_xxx
oracle 26478 oracle 8w REG 8,3 1497201 37093990 /u01/app/oracle/admin/test/bdump/alert_test.log_xxx
oracle 26480 oracle 6w REG 8,3 1497201 37093990 /u01/app/oracle/admin/test/bdump/alert_test.log_xxx
oracle 26480 oracle 8w REG 8,3 1497201 37093990 /u01/app/oracle/admin/test/bdump/alert_test.log_xxx
oracle 26482 oracle 6w REG 8,3 1497201 37093990 /u01/app/oracle/admin/test/bdump/alert_test.log_xxx
---可以發現這些檔案系統指向新的檔案名.
---在前面的會話執行alter system archive log current ;會出現什麼情況呢?
$ ls -l /proc/26687/fd | grep -i alert
--有建立新的alert檔案并打開新的句柄.
# lsof | grep -E 'alert_test.log$|PID'
oracle 26488 oracle 8w REG 8,3 459 37094613 /u01/app/oracle/admin/test/bdump/alert_test.log
oracle 26490 oracle 8w REG 8,3 459 37094613 /u01/app/oracle/admin/test/bdump/alert_test.log
oracle 26687 oracle 6r REG 8,3 459 37094613 /u01/app/oracle/admin/test/bdump/alert_test.log
# ps -ef | grep -E "26488|26490|26687" | grep -v grep
oracle 26488 1 0 08:04 ? 00:00:00 ora_lgwr_test
oracle 26490 1 0 08:04 ? 00:00:00 ora_ckpt_test
oracle 26687 26686 0 08:12 ? 00:00:00 oracletest (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
--如果你使用vim編輯看看,可以發現inode發生了變化.
$ ls -li alert_test.log
37095477 -rw-r----- 1 oracle oinstall 804 2015-05-05 08:37:08 alert_test.log
# lsof | grep -E 'alert_test.log|PID' | grep delete
oracle 26488 oracle 8w REG 8,3 805 37095459 /u01/app/oracle/admin/test/bdump/alert_test.log~ (deleted)
oracle 26687 oracle 6r REG 8,3 459 37094613 /u01/app/oracle/admin/test/bdump/alert_test.log~ (deleted)
--總之最好不好選擇檢視時,不要選擇儲存,最好選擇view模式.
2.再來看看11g的情況:
SYS@test> @ver1
------------------------------ -------------- --------------------------------------------------------------------------------
x86_64/Linux 2.4.xx 11.2.0.3.0 Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
# lsof | grep -i alert
--竟然沒有輸出.
SCOTT@test> @spid
SID SERIAL# SPID C50
---------- ---------- ------ --------------------------------------------------
580 7 3879 alter system kill session '580,7' immediate;
# ls -l /proc/3879/fd | grep alert
--換一句講,在寫alert*.log完成後,關閉了句柄.
--這樣即使編輯檔案等各種操作,基本不會導緻日志的丢失.
3.當然11G rac下又是不同的情況:
# lsof | grep -E "alert_|PID"
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
java 20101 root 60r REG 252,3 212216 10764708 /u01/app/grid/diag/asm/+asm/+ASM2/trace/alert_+ASM2.log
java 20101 root 61r REG 252,3 16654048 12142756 /u01/app/oracle/diag/rdbms/dben/dben2/trace/alert_dben2.log
java 20101 root 63r REG 252,3 409450857 12125590 /u01/app/oracle/diag/rdbms/dbcn/dbcn2/trace/alert_dbcn2.log
# ps -ef | grep 20101
root 20101 1 1 2014 ? 1-12:14:54 /u01/app/11.2.0.4/grid/jdk/jre/bin/java -Xms128m -Xmx512m -classpath
/u01/app/11.2.0.4/grid/tfa/dm01dbadm02/tfa_home/jlib/RATFA.jar:
/u01/app/11.2.0.4/grid/tfa/dm01dbadm02/tfa_home/jlib/je-5.0.84.jar:
/u01/app/11.2.0.4/grid/tfa/dm01dbadm02/tfa_home/jlib/ojdbc6.jar:
/u01/app/11.2.0.4/grid/tfa/dm01dbadm02/tfa_home/jlib/commons-io-2.2.jar oracle.rat.tfa.TFAMain
/u01/app/11.2.0.4/grid/tfa/dm01dbadm02/tfa_home
--這個是tfa的東東,好像以讀的方式打開.看來11G已經發生了變化,打開讀寫完成後,會關閉alert檔案的句柄.
![mybatis_入門程式Mybatis入門[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)