Mozark's blog

查看 dmesg 出現下列訊息 Jun  8 11:18:48 m4000b genunix: [ID 120576 kern.notice] basic rctl process.max-file-descriptor (value 256) exceeded by process 25319. Jun  8 11:19:05 m4000b genunix: [ID 120576 kern.notice] basic rctl process.max-file-descriptor (value 256) exceeded by process 25370. Jun  8 11:19:34 m4000b genunix: [ID 120576 kern.notice] basic rctl process.max-file-descriptor (value 256) exceeded by process 25377. Jun  8 11:19:35 m4000b genunix: [ID 120576 kern.notice] basic rctl process.max-file-descriptor (value 256) exceeded by process 25392. Jun  8 11:19:49 m4000b genunix: [ID 120576 kern.notice] basic rctl process.max-file-descriptor (value 256) exceeded by process 25485. 經過 Google 大神 的說明, 要在 /etc/system 加入 set rlim_fd_max=8192 set rlim_fd_cur=1024 因為這項設定必需經過重開機才能生效, 所以列為裝機後的必設參數

user 反應他的 jobs 手動執行正常, 但排程執行失敗

客戶反應本週 /root 備份沒有成功

今天幫一個客戶調校DB時看到了下面的 TOP SQL

環境 Oracle 10G active/standby node1 hostname = n1  IP x.x.x.1 node2 hostname = n2, IP = x.x.x.2 share IP = x.x.x.3 安裝完DB後,  Listener 聽 x.x.x.1 的 IP 時 , 可以連線至 EM, 若 Listener  聽 x.x.x.3 的 IP 時 , 則不能連線至 EM 解法: emca -deconfig dbcontrol db -repos drop 設定環境變數 $HOSTNAME emca -config dbcontrol db -repos create

基本上, 任何DB都不該列入VMware 的P2V 清單中, 但還是有 user 想要這麼做....

User 回報查詢一個  view 的內容跑不出來, 原始建 view 的 SQL statement 如下:

使用者來電表示 /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