SAP BusinessObjects Enterprise XI3.1-龐大系統內容的完整移轉

[Former Member]

當我們在談論SAP BusinessObjects Enterprise XI3.1(BOE)的內容移轉時，首先想到的都是使用BOE的工具「匯入精靈」，進行來源系統CMS 至目的系統CMS的內容移轉，或者是將來源系統的內容匯出成BOE的檔案交換格式，「Business Intelligence保存資源」也就是BIAR檔，再匯入至目的系統內。

使用匯入精靈進行BOE系統內容移轉的最大優點就在於「彈性」，匯入精靈的介面提供管理者挑選想要移轉的系統內容進行移轉，所以管理者可以選擇只移轉部分資料夾、報表；或者部分群組帳號、事件，完全依照管理者的需求，所以在小幅度的內容移轉情境下，匯入精靈無疑是最佳選擇。

但是若我們的需求是將整個BOE的系統內容完整移轉時，匯入精靈的限制就會顯露出來，當系統包含的內容非常多時，檔案大小也會非常的大，當然我們還是可以使用匯入精靈選取完整的系統內容做移轉，可是如果以BIAR檔案來移轉，檔案大小超過500MB以上，在匯入或匯出時就會發生失敗的狀況，如果把內容切分成多份較小的BIAR分別匯入，又會多出額外的規劃和作業時間，所以在大型的BOE系統上，使用匯入精靈搭配BIAR的移轉方式是沒有效率的。

雖然BIAR有檔案大小的瓶頸在，我們還是可以使用匯入精靈選擇CMS至CMS的移轉方式做完整匯入，但是這兩台機器必須在彼此可以溝通的相同網段之中，在一些大型的企業環境，通常驗證區和正式區會分開放在兩個獨立的網路環境，這個時候除非能將其中一個系統搬至另一個的網路環境才能使用匯入精靈，縱使如此，在4核心8GB記憶體的主機配備下，500MB的FileStore內容，就需要一個小時以上的匯入時間，所以內容龐大的系統使用匯入精靈進行CMS至CMS的移轉，所耗費的時間也是相當驚人的。

此時，我們就會開始考慮另一種移轉方式：Repository (RPS) & FileStore的移轉，從BOE的運作架構我們知道，只要把資料庫的索引資料和實體檔案的檔案內容一起備份，就可以在原機上還原整個BOE的系統內容。

然而我們現在談論的是系統和系統之間的移轉，來源和目的可能是主機名稱不同、兩台獨立的BOE系統，如果我們直接用原機備份還原的方式將來源端的RPS和FileStore放到目的端的機器上，目的端的Server Intelligence Agent (SIA)裡只有CMS服務可以啟動，其他服務是無法啟動的，因為此時的RPS裡記錄的服務伺服器都是來源端的名稱，而SIA的啟動資訊卻還是目的端的內容。

那麼要調整哪些部分才能令所有的服務都可以啟動，就如同完整的來源端系統呢？我們以下面的情境為例：

          假設我們在驗證區有一BOE XI3.1系統，有兩台包含CMS在內提供服務的主機做Cluster設定，後端連到同一個RPS資料庫，前端有一台安裝BOE的Web層功能的網頁伺服器，同時在正式區有另一BOE系統，安裝的系統架構、服務及路徑都和驗證區相同，作業系統和資料庫類型也一樣，但是每台機器的主機名稱都不同，如下圖：

假設我們在驗證區已經完成了系統內容的驗收，要將龐大的系統內容移轉到正式區去，首先當然要先把驗證區的RPS和FileStore備份出來，除此之外，在有安裝BOE的兩台CMS主機和一台Web Server上還需要備份幾個檔案，在BOE安裝路徑\Business Objects\BusinessObjects Enterprise 12.0\win32_x86這個資料夾下有幾個名稱為_boe的檔案(沒有安裝CMS服務的Web Server無.dbinfo這個檔案)，如下圖：

除了.install和.install.backup這兩個檔案以外，其他的檔案檔名都會帶有SIA名稱(通常也會是主機名稱)，將這三台主機的這些檔案也分別備份起來之後就完成了移轉的前置準備，同時也不要忘了養成良好的習慣，把目的端正式區的RPS、FileStore以及這些檔案也備份起來，以備不時之需。

接著就可以開始進行系統內容的完整移轉，首先將驗證區的RPS還原至正式區的DB主機上，為了簡化後面的設定，還原後的資料庫名稱以正式區本來的RPS資料庫名稱命名，如此也不需要調整資料庫連線設定。

RPS移轉完成後就是FileStore的移轉，把驗證區備份出來的FileStore移至正式區環境的相同路徑下，注意這裡指的相同路徑並不一定是預設路徑，而是驗證區的FileRepository服務設定的路徑，因為這些設定都會隨著RPS一起移轉過來。

到此為止都和原機的RPS & FileStore備份還原步驟一樣，然而就如同前面提到的，此時的RPS裡記錄的服務伺服器是驗證區的名稱，而SIA的啟動資訊還是正式區的，此時去啟動SIA將無法啟動CMS以外的服務，所以我們需要把驗證區的這些啟動資訊也移轉至正式區，這些資訊就在剛剛備份的那些名稱為_boe的檔案中，調整的方法根據安裝的BOE服務不同而有所差異。

在有安裝CMS服務的兩台BOE主機(CMS1P、CMS2P)，要將驗證區相應的這兩台主機(CMS1V、CMS2V)上的_boe檔案移至相同的路徑下，並將帶有驗證區主機SIA名稱的檔案名稱更改為正式區主機的SIA名稱取代原本的檔案，注意.dbinfo這個檔案不要移轉，沿用原本正式區的檔案，因為這個檔案記錄著CMS的資料庫連線資訊，需要沿用正式區的設定，移轉完成之後去開啟正式區主機的SIA內容，在啟動資訊裡應該要顯示驗證區的內容，如下圖：

而在另一台Web Server主機則不需要移轉這些_boe檔案，但是需要修改正式區主機上的.bootstrap檔案，將此檔案中sia後面的編碼更換成驗證區Web Server上相同檔案的編碼，如下圖：

完成這些調整之後，去啟動這三台主機的SIA，此時SIA裡的所有服務都可以順利啟動了，而且整個正式區的系統內容就跟驗證區一模一樣，甚至連伺服器的參數設定都一併移轉過來，如果是使用匯入精靈進行CMS至CMS的內容移轉方式，伺服器參數仍會保留正式區的設定，需要花費額外的時間去做調整，然而最重要的還是先前提到的：使用匯入精靈移轉龐大的系統內容將要耗費非常可觀的匯入時間；若使用這種移轉RPS & FileStore的方式，500MB的內容從複製檔案、還原檔案到修改SIA資訊，只要20分鐘以內就可以完成整個系統內容的移轉。

使用這種移轉RPS & FileStore的方式有幾個重點需要注意：

1. 無法挑選部分內容移轉，只能完整移轉整個系統內容。
2. 兩套BOE系統的環境要相同，如作業系統、資料庫類型要一樣，對應的主機所安裝的系統架構、服務及路徑必須相同。
3. 系統內容中跟網路環境相關的設定需考慮兩套系統的網路環境差異，如LDAP設定或連線使用的資料來源，移轉過後可能需要重新設定。
4. 由於系統的RPS整個換成來源端的內容，伺服器清單裡顯示的服務伺服器名稱會是來源端的名稱，可以手動修改伺服器的名稱屬性與目的端相同。

這種移轉方式最大的優點就是縮短內容移轉的耗時，當系統內容越龐大，使用匯入精靈匯入的移轉方式和RPS & FileStore的移轉方式需耗費的作業時間差距越大，但是RPS & FileStore的移轉也有一些限制在，缺乏匯入精靈那樣的彈性是它的缺點，綜合以上考量，最適合使用這種移轉方式的情境，就是在驗證區的內容已經驗收完畢後，要把龐大的系統內容移轉至正式區，因為通常驗證區和正式區的系統環境和架構一定會是相同的，而且需要移轉整個完整的BOE系統內容。