相信很多人都遇過在linux下要umount某個device時發生"umount: /u01: device is busy" 的錯誤.這個訊息代表要被umount的device正被process使用/user占用中.
此問題通常可用採以下幾個解法:
* 執行 lsof |grep XXX (XXX為要umount的目錄名稱)找出目前佔用此device的ProcessID/user,剔除掉該PID或請user離開該目錄後進行正常umount.
* 執行 fuser -m /dev/sdd1 則更直接的列出佔用此device的PID,剔除掉該PID後進行正常umount.
* 執行 umount -f /dev/sdd1 強制umount
* 若以上指令都無法生效時,就只剩下 umount -l /dev/sdd1 這種暴力umount的指令可以用了.這個指令常用於Networked File System(NFS)的 mount device.
PS: 但正常的作法應該是先停掉nfs service之後就可以umount了.
2009年3月25日 星期三
2009年3月14日 星期六
Cold Backup n Recovery (冷備份 n 還原)
Oracle DB提供了多種備份還原機制(Backup n Recovery Mechanism)來因應不同層級的備份需求. 其中主要可分為 Cold Backup(冷備份)與 Hot Backup(熱備份). Cold Backup 需在資料庫關閉的情況下進行, Hot Backup 則可在資料庫運行時備份. 這兩種備份機制各有其優缺點,端看組織需求來決定採用何種備份機制.
基於成本考量,並非所有組織都有額外的測試機來執行備份還原演練,但這卻是資安演練中不可獲缺的一環. 因此這個案例要在不影響 Production 的運作前提下,將每日 Production 的 Cold Backup 檔案,使用不同的 SID 與檔案目錄還原至同一台 Production 主機上,驗證該 Cold Backup 的有效性.
步驟:
1. 將每日備份的 cold backup files,完整複製(不包含 control files)至新目錄下.
2. 由 Production 的 spfile 來產生新 pfile,並修改相關參數至對應的 SID 與新目錄路徑.
SQL> create pfile from spfile;
3. 由 Production 的 crontol file 來建立一個文字型態的新 control file.
SQL> alter database backup controlfile to trace;
4. 編輯該 crontol file,複製由 CREATE CONTROLFILE SET DATABASE 開頭至 CHARACTER SET ZHT16MSWIN950 結尾的段落至新檔案 new_control.sql. 調整檔案內容至新的路徑與 DBNAME,並將 REUSE 改為 SET,NORESETLOG 改為 RESETLOG.
5. 修改 OS oracle user profile 的相關參數(ex:ORACLE_SID)
6. 使用修改過的 pfile 來啟動新 DB 至 NOMOUNT 狀態
SQL> startup nomount pfile='/u02/app/oracle/pfile';
7. 執行調整過的 new_control
SQL> @new_control.sql;
8. 將 DB 啟動至 OPEN 狀態
SQL> alter database open resetlogs;
最後可透過 select v$instance 與 v$recovery_log 來確定新 DB 已經開啟至正確狀態.
基於成本考量,並非所有組織都有額外的測試機來執行備份還原演練,但這卻是資安演練中不可獲缺的一環. 因此這個案例要在不影響 Production 的運作前提下,將每日 Production 的 Cold Backup 檔案,使用不同的 SID 與檔案目錄還原至同一台 Production 主機上,驗證該 Cold Backup 的有效性.
步驟:
1. 將每日備份的 cold backup files,完整複製(不包含 control files)至新目錄下.
2. 由 Production 的 spfile 來產生新 pfile,並修改相關參數至對應的 SID 與新目錄路徑.
SQL> create pfile from spfile;
3. 由 Production 的 crontol file 來建立一個文字型態的新 control file.
SQL> alter database backup controlfile to trace;
4. 編輯該 crontol file,複製由 CREATE CONTROLFILE SET DATABASE 開頭至 CHARACTER SET ZHT16MSWIN950 結尾的段落至新檔案 new_control.sql. 調整檔案內容至新的路徑與 DBNAME,並將 REUSE 改為 SET,NORESETLOG 改為 RESETLOG.
5. 修改 OS oracle user profile 的相關參數(ex:ORACLE_SID)
6. 使用修改過的 pfile 來啟動新 DB 至 NOMOUNT 狀態
SQL> startup nomount pfile='/u02/app/oracle/pfile';
7. 執行調整過的 new_control
SQL> @new_control.sql;
8. 將 DB 啟動至 OPEN 狀態
SQL> alter database open resetlogs;
最後可透過 select v$instance 與 v$recovery_log 來確定新 DB 已經開啟至正確狀態.
2009年3月11日 星期三
Oracle 資料庫字元集移轉 (Database Character Set Migration)
伴隨著組織擴張與全球化(Globalization)的需求與佈局,資料庫由特定國碼(ex:ZHT16MSWIN950)轉換到統一碼/標準萬國碼(ex:AL32UTF8)的資料庫字元集移轉 (Database Character Set Migration)就變成不可避免的趨勢. 然而,資料庫字元集移轉往往也是DBA與Programer所面臨最棘手的問題之一.
目前比較普遍使用的Unicode資料庫為AL32UTF8(變動長度1~3 bytes,增補字符集 4 bytes)與UTF8(變動長度1~3 bytes,增補字符集 2*3bytes=6bytes). 其中AL32UTF8是Oracle原廠建議採用的字元集.
另一種Unicode儲存資料的方法為使用NCHAR資料型態(NCHAR,NVARCHAR,NCLOB). 這種儲存於欄位的Unicode並不會受到底端資料庫字元集的不同而有所影響. 也就是說,資料在儲存進欄位時已經被自動編碼成Unicode. NCAHR的優點在於支援固定長度亞洲字元集(fixed-width character sets),藉此提供更好的亞洲字元資料處理效能.
NCHAR資料型態可分為兩種:AL16UTF16與UTF8. 其中AL16UTF16為系統預設的NCHAR資料型態.
移轉時最常發生的問題不外乎就是資料斷尾(Data Truncation),資料遺失(Data Loss)與資料損毀(Data Corruption). 這些問題必須在移轉前考量到,並透過嚴謹的移轉計劃(Migration Plan)來避免.
移轉的方法大致可歸納為三種:
1.使用Full Export and Import
2.使用Alter Database Character Set Statement
3.使用Alter Database Character Set Statement及選擇性的Imports
第一種方法適用在絕大部分的案例,但須特別注意資料斷尾與資料遺失的問題.
第二種是最快速移轉的方法,但也因為所須滿足該方法的前提太多,除非能確定要移轉的DB已經滿足了全部要素,不然不建議採用.
第三種方法適合於充分了解資料的分布並且所需移轉的資料僅佔用極少數的Tables時.
但不管採用哪種移轉方式,都必須兼顧到移轉後資料完整性(Data Integrity)與最少程式調整負擔(Modification of Minimum). 與前端AP開發人員良好的溝通協調是達成此目標的不二法則.
目前比較普遍使用的Unicode資料庫為AL32UTF8(變動長度1~3 bytes,增補字符集 4 bytes)與UTF8(變動長度1~3 bytes,增補字符集 2*3bytes=6bytes). 其中AL32UTF8是Oracle原廠建議採用的字元集.
另一種Unicode儲存資料的方法為使用NCHAR資料型態(NCHAR,NVARCHAR,NCLOB). 這種儲存於欄位的Unicode並不會受到底端資料庫字元集的不同而有所影響. 也就是說,資料在儲存進欄位時已經被自動編碼成Unicode. NCAHR的優點在於支援固定長度亞洲字元集(fixed-width character sets),藉此提供更好的亞洲字元資料處理效能.
NCHAR資料型態可分為兩種:AL16UTF16與UTF8. 其中AL16UTF16為系統預設的NCHAR資料型態.
移轉時最常發生的問題不外乎就是資料斷尾(Data Truncation),資料遺失(Data Loss)與資料損毀(Data Corruption). 這些問題必須在移轉前考量到,並透過嚴謹的移轉計劃(Migration Plan)來避免.
移轉的方法大致可歸納為三種:
1.使用Full Export and Import
2.使用Alter Database Character Set Statement
3.使用Alter Database Character Set Statement及選擇性的Imports
第一種方法適用在絕大部分的案例,但須特別注意資料斷尾與資料遺失的問題.
第二種是最快速移轉的方法,但也因為所須滿足該方法的前提太多,除非能確定要移轉的DB已經滿足了全部要素,不然不建議採用.
第三種方法適合於充分了解資料的分布並且所需移轉的資料僅佔用極少數的Tables時.
但不管採用哪種移轉方式,都必須兼顧到移轉後資料完整性(Data Integrity)與最少程式調整負擔(Modification of Minimum). 與前端AP開發人員良好的溝通協調是達成此目標的不二法則.
訂閱：
文章 (Atom)