window冷備份恢複至linux

以前做window到linux的遷移都是用的常規的exp和imp的方法來遷移的。利用邏輯備份，從而實現跨物理結構和os的資料移轉。這樣的方
法我相信有不少的朋友都是這樣的做的。

今天有一個50g的資料庫，需要重window的平台，遷移到linux的平台。這幾天剛好在看資料檔案的物理結構，看到大家提供的物理結構的文
檔，並沒有OS的差異上的區別，那麼是不是意味著在不同的os上的資料檔案等是不是結構都是相同的了，物理結構的文檔還沒有研究完，所以還沒有寫程式來驗
證的能力，等研究完結構，再來寫程式來解讀檔案來驗證了，不過有了前面的猜想，我就有一個大膽的想法，既然如此，我就直接用用這個window的冷備份看
能不能恢複到linux上，從而來進行一個實際動作上的驗證了。要是成功的話，一舉兩得，即驗證了自己推斷，有能夠快速的給使用者移轉了。

立馬行動吧。

原系統
OS： window 20003 64bit
Oracle: 10.2.0.1
單一實例

目標系統
OS：RHEL 4.7 64bit
Oracle： 10.2.0.1
單一實例

根據客戶的需要，做遷移。

1. 查詢所有的logfile

SQL>select * from v$logfile;

2. 查詢所有的資料檔案

SQL>select * from v$datafile;

3. 先關閉來源資料庫

shutdow immediate

4. 備份備份記錄檔，資料檔案

5. 啟動資料庫到read only狀態，是客戶資料庫還可以提供服務
startup mount;
alter database open read only;

6. 複製資料庫檔案，記錄檔到目標伺服器上
這裡規劃的目錄和源庫上的不同。
資料檔案都放在/u01/app/oracle/oradata/towell/datafile下
控制檔案放在/u01/app/oracle/oradata/towell/controlfile下，並修改其中一個名字為current.1給底下
的pfile使用。
記錄檔放在/u01/app/oracle/oradata/towell/onlinelog上，做完了，總結了一下，redo可以不遷移的，畢竟是
冷備份。
並建立好/u01/app/oracle/admin/towell/下的一些列dump目錄。

7. 現在就在目標資料庫上開始動作了。
先建立密碼檔案
orapwd file=$ORACLE_HOME/dbs/orapwtowell password=mypassword
建立pfile檔案
這個pfile檔案最方便的是從源庫匯出後copy過來
create pfile=’d:/backup/init.ora’ from spfile;
修改其中的相關參數，包括路徑，並修改control_files到一個路徑，比如這裡的control_files=’/u01/app/oracle
/oradata/towell/controlfile/current.1′

這裡的兩個步驟可以提前準備，這樣可以更節省停機時間。

8. 從pfile啟動資料庫到mount階段。
這裡就是開始擔心的地方了，首先controlfile會不會出現os不同而不相容的現象了，如果這裡能夠成功的話，我想資料檔案基本上也可以搞定了。
看到螢幕上出現
startup pfile=’d:/backup/init.ora’ mount;
Database mounted.
心裡暗自感覺，自己離成功已經開始了第一步了。

9.
匯出controlfile,注意這裡不能直接open了，直接open，肯定會提示資料檔案不能開啟的提示，因為控制檔案時window下的，裡面的路
徑全是window的。所以我們到處控制檔案，重建之。

alter database backup controlfile to trace;
oradebug setmypid;
Statement processed.
oradebug tracefile_name;
/u01/app/oracle/admin/sample/udump/towell_ora_21214.trc

10. 開啟這裡的trace檔案。裡面就可以看到重建的controlfile的sql語句了
把其中的資料檔案的路徑和記錄檔的路徑
按照現在的linux的路徑修改過了。這雷根據上面的datafile的select的結果，對應上，注意順序保持控制檔案裡已有的順序，不要修改順序，
僅修改路徑就可以了。使用者這裡總共有30多個資料檔案。不需要一個一個的改了，替換就可以了。修改完畢。
我在重建的時候不喜歡用reuse，所以把reuse改成了set，把noresetlogs改成resetlogs。如下
CREATE CONTROLFILE SET DATABASE “TOWELL” RESETLOGS ARCHIVELOG
…….

11. 再次關閉資料庫，以便重建controlfile
shutdown immediate;
startup pfile=”d:/backup/init.ora’ nomount;
執行上面修改好的create controlfile 的 指令碼
非常順利，
提示控制檔案建立成功。

12. 帶著激動的心情開啟資料庫吧
alter database open resetlogs;
看著記錄檔裡的日誌，勝利在望叻。
就正在得意的時候，螢幕中斷。提示資料庫open失敗，勝利instance。

Database Characterset is ZHS16GBK
Fri Apr 16 13:40:50 2010
Errors in file /u01/app/oracle/admin/sample/bdump/sample_smon_7134.trc:
ORA-00604: error occurred at recursive SQL level 1
ORA-04031: unable to allocate 16 bytes of shared memory (”shared
pool”,”select null from obj$ where …”,”sql area”,”kglhin: temp”)

看到這裡的資訊，很興奮，因為我知道既然這裡都已經可以看到我們的604的錯誤了，估計資料庫載入應該是可以了，只要block沒有衝突就可以了，
而且根據這裡的提示，應該是shared pool的問題。

開啟這裡的trc檔案，

Chunk 25709420 sz= 304 freeable “kks cstat ”
Chunk 25709550 sz= 32 freeable “kks pstat ”
Chunk 25709570 sz= 304 freeable “kks cstat ”
Chunk 257096a0 sz= 32 freeable “kks pstat ”
Chunk 257096c0 sz= 304 freeable “kks cstat ”
Chunk 257097f0 sz= 32 freeable “kks pstat ”

******************************************************
******************************************************
===============================
End 4031 Diagnostic Information
===============================
Warning: out of shared memory loading library cache object
[handle=257dde8c] select null from obj$ where obj#=:1 and type#=:2 and
obj# not in (select p_obj# from dependency$ where p_obj# = obj$.obj#)
*** 2010-04-16 13:40:50.996
SMON: following errors trapped and ignored:
ORA-00604: error occurred at recursive SQL level 1
ORA-04031: unable to allocate 16 bytes of shared memory (”shared
pool”,”select null from obj$ where …”,”sql area”,”kglhin: temp”)
Warning: out of shared memory loading library cache object
[handle=257e5d2c]
select obj#,type#,ctime,mtime,stime,status,dataobj#,flags,oid$, spare1,
spare2 from obj$ where owner#=:1 and name=:2 and namespace=:3 and
remoteowner is null and linkname is null and subname is null
*** 2010-04-16 13:40:51.045
SMON: following errors trapped and ignored:
ORA-00604: error occurred at recursive SQL level 2
ORA-04031: unable to allocate 4108 bytes of shared memory (”shared
pool”,”select obj#,type#,ctime,mtim…”,”Typecheck”,”kgghteInit”)

這裡的問題是，由於目標系統的記憶體比原來的系統大，所以想到要調整sga_target的，我就在pfile裡沒有設定sga_target。
sga_target查出來只有117M。確實是太小了。導致出現這個問題，shutdow執行個體，
把pfile建立為spfile。後修改sga的值，根據客戶的OS的記憶體實際大小，客戶是16G，sga_target先給5G了。
再次啟動。
看著日誌，直到最後出現ORACLE instance started.

資料庫沒有出現問題了。

通知客戶，把應用的datasource切換過來，跑了半個小時，目前還沒有發現問題。也不知道這樣的遷移會不會導致其他的問題。先試了試rman
和歸檔，沒有問題出現。由於本身是基於物理恢複的。
所以還是建議客戶週期性做exp的邏輯備份，反正多備份也沒有壞事，雖然現在成功了，但是也不代表這樣的方式沒有帶來災難行的問題，所以多保險一下吧。

物理的備份和恢複就是快，安裝以前的邏輯備份的話。50G的資料匯出，也需要半個多小時。而這樣備份的方式整個應用read
only的過程也就不到10分鐘。以後就在也不用exp/imp來做類似這樣的遷移了。