Oracle資料庫從Window XP遷移到Win7的詭異問題

最近公司的所有的作業系統都統一升級到Win7系統。我們公司有一個做工程計劃的ORACLE 的一個產品軟體叫Primavera Six(簡稱P6). 所以我需要把P6 的資料庫從XP遷移到Win7系統。因為以前也做過從XP 到 XP系統的P6資料庫的遷移成功過，而且是一次成功，沒有出什麼問題的。這次就沒有在做遷移之前做測試。呵呵，有點自信過度了，以後一定要先做測試，否則如果是限制時間做資料庫遷移的話，尤其是幫客戶做項目的話，那可就被領導和客戶批評了，還好我這次是自己公司的資料庫，而且對時間要求不限制。我可以有幾天的時間去尋找回複不成功的原因。下面我來說說這個遷移的故事吧。

2014年4月10日早上就寫郵件給相關用P6系統的同事，告訴他們，我從4月10號到4月11號做伺服器的資料庫遷移，所以在此其間資料庫用不了。其實要不了這麼長時間，主要是我們公司安裝卸載程式還需要專門的人員授權才可以操作軟體，所有的軟體都不能在沒有授權的情況下安裝或者卸載，有點變態哦，哈哈。這也好，我就吧遷移時間說長點。我4月10日就和IT說，我4月11日要升級OS到WIN7，我今天把資料庫和相關的軟體做好備份，當然這個伺服器裡還有MYSQL資料庫等資訊。今天重點是說ORACLE的資料庫的備份。MYSQL我自己寫了個每天自動備份的小批處理，基本遷移到WIN7沒有問題。於是我就把資料庫做了幾下日誌切換:alter system switch logfile。我還是做兩手準備吧，因為資料庫比較小。

1，所以做一個全庫冷備

a, 把資料庫關閉 shutdown immediate 。

b,把所有的資料檔案都拷貝下了, 包括tempfile,datafile,redo logile,controlfile等等

2，在資料庫mount下用RMAN做一個全庫備份。

a, RMAN的配置如下：

RMAN> configure channel device type disk format 'd:\bak\backupset\%U';

RMAN> CONFIGURE CONTROLFILE AUTOBACKUP on;
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO 'd:\bak\ctrlbak\%F';

RMAN> CONFIGURE RETENTION POLICY TO REDUNDANCY 5;
RMAN> CONFIGURE RETENTION POLICY TO recovery window of 5 days;
RMAN> backup as compressed backupset database plus archivelog;

 

b,從上面可以看出我備份的檔案路徑分別是：

控制檔案自動備份的配置給設定好：CONFIGURE CONTROLFILE AUTOBACKUP on;

控制檔案路徑：d:\bak\ctrlbak

資料檔案路徑：d:\bak\backupset

 

C， 開始用RMAN做備份

RMAN〉BACKUP DATABASE;

備份完畢後，把d:\bak下的檔案拷貝起來，同時把online redo log檔案也拷貝下來，這個到後面，回複的時候我會告訴你的用處。再把其他的要備份的備份到移動硬碟上去。

4月10日就這樣結束了，等待4月11日IT給吧XP的系統給抹掉，裝上WIN7 系統再做回複。

 

4月11日，IT從早上一直搞到下午3點，才把OS升級到WIN7。於是，我就立即準備把MySQL安裝上，把MYSQL的資料庫回複上，MYSQL資料庫恢複一切順利，不到1個小時搞定，再把我自己開發的用戶端程式安裝下，串連下MYSQL資料庫，一切正常。我開發的資訊系統順利串連上MYSQL資料庫，用戶端程式運行正常。下面就是開始著手安裝Primavera Six,當然這個軟體是自動的把ORACLE的資料庫一起安裝的，這個軟體依然用的是ORACLE10.2.0.1.0的版本。用了差不多30分鐘，P6安裝好了。這個安裝P6其實也是有一段很有趣的故事的，下面我來講講次故事：

因為我們的WIN7不是不一天安裝的，公司人比較多，IT分了三個星期的時間分批安裝，我一個同事在一周前安裝P6的時候，發現不能用。後來讓我去看下是什麼原因，我查了下資料庫，當我做資料庫連接配置的時候，系統竟然說我沒有許可權在C:\Program Files (x86)\ ，具體的目錄記不得了，寫檔案。串連資料庫的配置是需要寫資料庫配置資訊到本來磁碟的，竟然說我沒有許可權寫的許可權，我自己的電腦啊，我很納悶，於是問我們的IT，他們說是公司的POLICY，所有的使用者都沒有administrator的超級使用者的許可權，這個許可權在他們IT那。我當場暈死，奇葩吧。呵呵！沒有辦法，公司的POLICY，我們必須遵守。於是我嘗試到C:\Program Files (x86)目錄下建立一個檔案夾，系統提示我需要輸入使用者名稱和密碼驗證，又一次當場暈倒，不讓我建立目錄，需要檢驗，怪不得程式沒有辦法寫資訊到此目錄，於是我返回到C盤根目錄下嘗試建立一個檔案夾，不需要驗證，證明我是可以在C盤根目錄下有寫的許可權的。你有可能會問我，為什麼把資料庫和系統硬碟安裝在一個磁碟即C盤啊，這個我也不願意啊，我們所有的電腦都只有一個分區盤即只有一個C盤。是不時覺得奇怪，你可能會問，難道不怕中病毒吧系統硬碟給搞壞了，那資料庫不遭殃了啊。這個您放心，我們公司的殺毒軟體還是可以的，監控不錯。當然如果是磁碟壞了，我也沒有辦法了。通過上面的分析，我就分析，我們在用C:\Program Files (x86)下的許可權有問題，由於很多安裝程式都是預設安裝到C:\Program Files (x86)下面的，所以導致了我們沒有許可權和沒有辦寫資料庫設定檔到本地的受許可權控制的目錄。所以我把P6卸載了重新安裝，此時我把安裝目錄放到C盤的根目錄下，花了20分鐘，安裝成功。當然，這個時候設定資料庫也是成功的。此故事講完了。

接著上面資料庫恢複的事情，資料庫安裝好了後，我就把我用RMAN備份的資料拷貝到這個電腦的C:\bak\下。我就準備用RMAN做恢複操作，具體步驟如下：

a, 把資料庫打到nomount 狀態下。

SQL>startup nomount;

b,  用命令列啟動RMAN介面, 具體命令是：

C:\>RMAN TARGET  sys/pwd  

b, 恢複備份的控制檔案,具體命令如下：

RMAN>restore controlfile from 'disk path';

C, 控制檔案恢複好了，我就可以把資料庫置到mount狀態了，這個樣RMAN就可以讀控制檔案裡的資訊來恢複資料庫了，我用的是controlfile，沒有用catalog。所以這些資訊都是儲存在control file裡的。把資料庫置為MOUNT下，在RMAN裡操作的命令如下：

RMAN〉sql ' alter database mount';

mount成功我就可以開始restore database了。

D，還原資料庫

RMAN>restore database;

還原失敗，如：

從上面的提示可以預測到是沒有找打備份組檔案。我是有備份檔案的啊，檔案的就在c:\bak\backupset  和c:\bak\ctrlbak裡分別是資料檔案和控制檔案的最新備份啊。為什麼沒有找到呢？ 於是我就是RMAN肯定是通過control file裡的記錄資訊來找備份檔案的路徑的，於是我就猜測RMAN記錄的路徑裡沒有檔案可能。我可以用list backup來看下備份組的路徑在哪裡。

請看：

從上面可以看出，控制檔案裡記錄的備份組路徑是d:\bak\backupset目錄。而我的備份檔案是拷貝在c:\bak\backupset裡的，當然RAMN會出現上面的錯誤了，說找不到備份檔案。但是現在我有又悲劇了，上面說過我們的電腦只有一個C盤，沒有其他的盤符了。沒有辦法只有想辦法把資料拷貝移動硬碟上，然後想辦法把移動硬碟我需要的備份資料的盤符設定為D盤，然後再上面建立bak\backupset路徑，並且把備份檔案拷貝到此目錄下，進行恢複了。等路徑都設定好了後，再次重新restore database.如：

 

 從上面的顯示(reading from backup piece d:\bak\backupset\3AP5A2E3_1_1)可以看出這個時候讀取的檔案就是我備份的檔案。正常情況下應該是會成功的。

 從上面可以看出restore是成功的。下面我們再來進行recover database

RMAN>recover database;

 我recover database的時候，提示少了一個log，應該是少了線上redo log.這個也就是我在上面說的要把redo log也拷貝備份下的原因。把備份的online redo log拷貝到相應的位置，繼續做recover database,如：

這次recover database成功了。

下面再開啟資料庫，由於資料庫做了recover，所以需要用resetlogs開啟資料庫了，命令如下：

RMAN>sql 'alter database open resetlogs';

到此我用RMAN恢複資料庫成功了。此時心裡很高興。但是我的悲劇是是沒有結束，且看下面我的悲劇又來了。

既然資料庫都恢複成功了，那我就開啟P6的應用程式看下能否使用，當我開啟的時候，一開始程式載入資料是沒有問題的，但是載入了一會兒後，就突然跳出一個視窗如下：

 

 

上面的錯誤提示出現了，我只能從上面判斷是應用程式沒有成功的把資料庫成功載入。不知道是什麼原因導致的。我第一反應是是不是XP系統到WIN7的原因，於是我找IT找了台XP的系統，並且在上面做了一下上面同樣的恢複動作，同樣是資料庫恢複沒有問題，開啟P6應用程式出現的時同樣的錯誤提示，於是排除和作業系統有關係的原因。

這個時候我開始通過SQLPLUS登陸到資料庫，查詢下相關的表

我查dba_data-files沒有問題，

我查dba_temp_files 時出現一個錯誤說我TEMP檔案損壞不可以讀取。具體的當時沒有截屏下來，於是我恍然大悟，是暫存資料表空間壞了，導致P6系統在登陸的時候，提示一個詭異的錯誤，說資料載入不成功，因為載入資料的時候需要用到暫存資料表空間做排序等等動作。於是我重建立立了一個暫存資料表空間，命令如下：

Create temporary tablespace TEMP1 tempfile 'C:\oraclexe\oradata\XE\TEMP1.DBF' size 64M autoextend on maxsize 2G

extent management local uniform size 1M

把TEMP1設定為資料庫預設暫存資料表空間：

alter database default temporary tablespace TEMP1;

再把TEMP的損壞的暫存資料表空間給刪除掉。

Drop tablespace TEMP including contents and datafiles;

再次登陸P6用戶端應用程式，終於成功了。

 

對這次的故事我做出以下的總結：可以說是自己的一個lessons learned吧。

A， 做正式資料庫遷移之前一定要類比的嘗試測試下，免得會在正式遷移的時候，出現奇怪詭異的問題，不知所措。

B， source database 的伺服器和Target database的伺服器一定要最好是盤符，路徑規劃都一樣。就不會出現我的恢複的過程中，出現找不到備份檔案的問題。

C， RMAN 做備份的時候一定要把online redo log備份下，否則我出現我上面最後recover database出現找不到log的問題

D， 資料庫恢複到Target伺服器上後，一定要檢查下資料庫的邏輯檔案是否都正確，例如：dba_data_files, dba_temp_files 等等，否則會出現我的TEMP檔案壞了，出現奇怪的問題。

 

到此整個ORACLE 從XP到WIN7遷移的詭

 

異的故事結束，謝謝！