庫洛的異想世界

這禮拜遇到一個難以解釋的狀況...
就是公司的RD跟我說...他create table遇到lock...
沒錯就是lock....
table lock 是一種資料庫的保護措施..
如果有人正在使用該table...且不能被干擾...
就會有lock的情況產生
當然sql語法沒寫好或是index沒設定好也會有...
但是create table..真的第一次遇到..
在開啟db2 lock的snapshot後，kill 掉application
還是create失敗
於是我下了 db2 list tables for schema XXXXX | grep table's name
疑...看不到了ㄟ...
onemore time
下完create 指令 整個hand住...
於是開始檢查相關資訊...
這時候業務經理走過來...不能create table..會不會是空間不足阿
當時心想..這種問題問我..不是看輕我嗎??
我有那麼low嗎???
我就說...要是空間不足應該會拋出57011的sql error code....
但是因為無解..還是查看看好了
df -h 恩  空間很夠..非常夠
db2 list tablespaces show detail
靠...找到兇手了
表空間不足~"~...
後來歸納原因...
該資料庫是使用DMS空間
也就是create table 時會先給空間給他...
所以他比表空間是SMS的資料庫更占空間
而當初的表空間還有一點free page...
但是不夠create table(沒錯 還有freepage..所以不拋57011...= =凸)
總之學到一次經驗了
下一次就一個一個檢查好了
不要以為自己懂很多...
這對學習或是work都容易出現看不到的致命缺點
共勉之阿~~~~~~

linux如果遇到空間不夠大..
可以重新給顆硬碟..重新mount一個分割區
這時候做法如下

STEP 1
先mount 新硬碟，進行rsync 的動作(說穿了就是把舊硬碟的資料複製到新硬碟去)
已/home 爆掉為例 新硬碟mount在 /mnt/newhome
# rsync -av /home  /mnt/newhome &
其實rsync跟cp很接近..但會選擇rsync就是在於..萬一session中斷.cp等於失敗，rsync可以再做 會比較符合經濟效率
至於拋不拋背景就見仁見智了

有時候在進行超過一T的檔案備份還原....
常常不知道到底有沒繼續在跑...
這時候就可以下這個指令
db2 list utilities show detail
你可以看到該程序目前進度為百分之幾...
另外可以使用備份同時拋到背景執行...
避免session被踢掉....

rename kulo KULO kulo*
以上述為例....
這是把當下目錄中的kulo開頭的檔案
修改成KULO開頭.....
指令用法說明如下
rename 要取代的字串 取代後的字串 檔案名稱
kulo* 代表kulo開頭的所有檔案...
打完收功

最近公司打算搞新的WEB AP....
於是需要測試環境...
為了讓幾個SE都能看到相關流程...
我們選了大家都很熟的VNC來操作
ㄧ些簡單的操作指令如下：
vncpasswd：
設定該使用者用vnc登入的連線密碼...
/etc/init.d/vncserver start：
啟動VNC服務..

疑....版主上班的公司是使用JAVA開發環境
為何會扯到PHP&MYSQL勒...
因為以前是用上述軟體...所以也要摸一點>"<...

其實每天都有再玩DB2....
想到很久沒更新了....
就來說說DB2的還原好了
聽說DB2備份在上一年很久以前說過(遠目....)

很多程式都需要補丁來修補
DB2也不例外
昨天就做了db2V9.5的fix pack1 update
步驟如下：
準備動作：
  (1)下載db2 fixpack
  (2)安裝空間至少600 MB以上
  (3)所有與db2有關會寫入記憶體的行程要關掉
        可以用ps aux | grep db2查詢行程
     (a)db2stop force
     (b)讓instance不會自動帶起
          /home/db2inst2/sqllib/bin/db2iauto -off db2inst2
     (c)讓DAS不會自動帶起
          /opt/IBM/db2/V9.5/das/adm/dasauto -off
         (安裝完預設dasauto只有read的權限，請先下chmod +x /opt/IBM/db2/V9.5/das/adm/dasauto)
     (d)如果還有，評估是否要用kill來刪除(強烈、非常不建議，這風險超高，可是昨天就是這樣下= =..)
         如果處理得當，應該是不需要這步驟...
  (4)reboot DB2 server，讓有關DB2的行程都暫停
解開fixpack的tar檔(利用tar指令...這個有摸過linux的都知道...)
cd v9.5fp1/server
./installFixPack -b /opt/IBM/db2/V9.5
(執行db2level，可以查看db2安裝路徑EX：/opt/IBM/db2/V9.5)
結束後，再把所有關掉的服務開啟，reboot DB2 server就可以了
如果安裝失敗，會有說明log檔，去觀看並處理掉就可繼續執行。

最近因為許多事...
不得不開始正視DB2這東東
以下是最常下的一些指令

轉換成instance使用者後
下db2就可以變成下達SQL語法模式
db2=> select * from table1
如果不想轉換模式也可以用下面方式在linux上執行
db2 "select * from table1"
查看有幾個資料庫及相關資料
db2 LIST DATABASE DIRECTORY
查看資料庫data1的參數設定
db2 get db cfg for data1
如果有db2 connect to data1
可以改下db2 get db cfg
查看instance參數設定
db2  get dbm cfg
觀看所有tablespace
db2 list tablespaces show detail

昨天駐點單位提了一個需求...
就是不希望我用root來監控server的log檔
像第一天上課書上就有說【能不用root就不要用root的權限與帳號】因為root權限太大了，就跟windows裡的administrator一樣
這樣問題就來了!!!