Mozark's blog

使用者來電表示 /db 的空間被用完了, 查出是 listener 的 trace file 及 log file 的 size 暴增...., trace file 約莫已用了 6GB -rw-r--r--   1 oracle   dba      6359755059  1月 19 10:20 listener.trc -rw-r--r--   1 oracle   dba      122592751  1月 19 10:22 listener.log 我直覺不外乎三個原因 1. connect 激增 2. hacker 3. 變更 listenr 的 log level 原因三很容易排除, 原因二及原因一由 log 中就可以找到, 果不其然, 不但找到是哪一個 IP , 也找到從今年開始的出現 connect 次數暴走, 從每一至數分鐘一次, 變成每分鐘數次, 問題還是回到 AP 層, 使用者後來查出那台是出勤系統, 要將資料寫入DB失敗後就持續的嘗試 但為什麼會失敗呢? 答案令人很無言, 因為 table 中儲存出勤日期是用6 bytes 的中式日期, 到了民國一百年後, 就出問題了, 這是我遇到的第一支百年蟲. 為什麼寫入失敗沒有人發現呢? 因為還沒有領一月份的薪水.  呵 ! 呵 ! 呵 !

在 Oracle10g 以前，DBA 往往要計算大量統計資訊才能了解資料庫的效能及負載, 比如 database buffer hit ratio , library cache hit ratio , or physical reads per second. 為了要計算這些統計資訊, DBA 需要寫一些複雜的 SQL 來 join 那些 V$ 的 VIEW (i.e.  v$sysstat and v$statname), 而這些查詢都要消耗部份的 resource, 並且 DB 造成一定程度的負擔.

終於到到搬家的日子, 從星期五就開始打包.

下午到某科技大學查看 RMAN backup 使用的空間愈來愈大原因. 因為在 cron table  中的 RMAN backup script 中有加了 Delete noprompt obsolete , 理論上應該在備份完 level 0 的 backup set 後, 會自動清除過期的 backup set 才對, 可是因為某種原因在某個日期以前的  backup set 就一直沒有清除 環境 OS : AIX 5.3, Oracle 9.2, RMAN 備份不使用 catalog DB Cron table : 30 3 * * 0  /oracle/scripts/rmanbk_lv0     > /dev/null 30 3 * * 1,3,5  /oracle/scripts/rmanbk_lv1 > /dev/null 30 3 * * 2,4,6  /oracle/scripts/rmanbk_lv2 > /dev/null 步驟: Check RMAN backup script , 沒什麼異常 RMAN> run{ 2> backup 3> incremental level 0 database 4> filesperset=3 5> format '/oracle/archive/rmanbk/lv0_%t_%s_%p'; 6> sql "alter system archive log current"; 7> backup archivelog all; 8> delete noprompt obsolete ; 9> } Check RMAN configuration, 注意 RETENTION POLICY 設成  REDUNDANCY 1 RMAN configuration parameters are: CONFIGURE RETENTION POLICY TO REDUNDANCY 1; CONFIGURE BACKUP OPTIMIZATION OFF; # default CONFIGURE DEFAULT DEVICE TYPE TO DISK; # d