SharePoint 資料遷移解決方案

　　前言：說來慚愧，我們的SharePoint内網門戶跑了2年，不堪重負，資料量也不是很大，庫有60GB左右，資料量幾萬條，總之由于各種原因吧，網站速度非常慢，具體問題研究了很久，也無從解決，所有考慮用Net重新搭網站，進行資料遷移，也就帶來了資料遷移這個問題。

　　思路：由于SharePoint的架構和Net有着不一樣的特點，而且SharePoint的資料庫設計是不為人所知的（當然我們可以了解一些，但不完全），雖然也是基于Net架構的，但是我們很難做到Sql To Sql的方式。是以，隻能考慮伺服器端對象模型，插入到資料庫中的方式，其間，經理給的建議非常合理，就是将SharePoint的資料整理好插入中間庫，然後統一插入到新網站資料庫中。在後來的實踐中，發現這一方法對資料遷移和檢查，都有着非常好的幫助，避免了很多SharePoint對象模型中出錯，但是不好更正的現象。

　　中間庫設計：

　　考慮到原内網門戶有清單、文檔庫、圖檔庫三種主要類型（特殊清單特殊對待），是以建立了兩個資料庫表，分别用來存List和DocLib，同時再建立兩個表Image和Attachment用來存清單正文中的圖檔和清單附件（文檔庫文檔當做清單附件）。

　　一、用來存儲清單内容的表 --  TABLE [dbo].[List]

　　二、用來存儲文檔庫/圖檔庫的表 -- TABLE [dbo].[DocLib]

 　　三、用來存儲正文圖檔的表 -- TABLE [dbo].[Image]

 　　四、用來存儲附件集的表 -- TABLE [dbo].[Attachment]

　　代碼方法段：

　　首先就是對象模型讀取清單插入List表，然後是對象模型讀取文檔庫/圖檔庫插入DocLib表，讀取字段的代碼比較簡單，我們就不過多介紹，就介紹下其間遇到的幾個問題，也避免代碼太多太繁雜。

　　問題一：正文亂碼

　　這是一個比較操心的問題，插入資料沒有問題，但是到新系統顯示，發現好多正文帶有雷系”？“之類的東西，這樣子肯定不行，首先想到RePlace，然後想想不太靠譜，因為正文裡很有可能有正常的問号，這樣會被替換掉。後來想到可能是編碼問題，後來證明确實是編碼問題，将特别的空格處理替換為 即可，處理如下：

　　問題二 進行中途報錯

　　插入過程中，我們會出現一些操作異常的情況，可能整個程式要運作4-5個小時，但是4個小時的時候，出現異常了，我們很惱火，調試也很困難，因為很難去調試問題，即使把斷點打在Catch裡面，調試也是力不從心的，是以，我們必須一次成功，不容許中間出差錯。這樣，我采取了空跑程式（隻走對象模型，不插入資料庫，因為Insert很慢，而且幾乎不報錯，錯誤多數出現在對象模型調用上，各種字段沒有、對象為空）和記錄錯誤補錄兩個方式，來避免這樣的問題。

　　問題三 進行中間的小錯誤

　　操作過程中，對于代碼編寫的可靠性，要求很好，就像上面所說，一個要跑4-5個小時的程式，4個小時的時候報錯，我們基本就屬于前功盡棄，因為繼續插入是很困難的。是以中間的小問題，對于代碼段的可靠性要求，就非常高了。必要的時候，多加一些Try...Catch...可能會對于效率有一點點影響，但是對于整個程式來說，是非常必要的。

　　問題四 提取正文中的圖檔URL

　　我們資料遷移過程，正文中會帶有圖檔，這就要求我們把圖檔儲存下來，遷移過去，然後還要插入到相同的位置。這是個比較讓人頭疼的問題，首先說下邏輯，讀取正文的時候，用正規表達式擷取所有的圖檔（不是絕對路徑的要拼成絕對路徑），然後插入到Image中間庫中，将原來圖檔的位置，替換為一個圖檔标志，因為之後我們還要把圖檔插入到這裡。

　　問題五 将正文中的圖檔Url換為辨別<ImgType>

　　同樣使用正規表達式，将圖檔标簽<img.../>替換為我們特定的辨別，為将來replace回來做準備，代碼附下：

　　中間庫到新系統：

　　經過将SharePoint中資料，整理插入到中間庫的過程，我們等于已經完成80%的工作，因為剩下的内容，就是Sql To Sql的問題了，對于net開發人員，甚至不需要設計，你隻需要了解新系統的資料庫結構，相應字段插入就可以了。唯一要提到的就是附件/圖檔處理的問題，下面我說下我的處理方式：

　　附件/圖檔處理

　　這也是一個比較棘手的問題，因為衆所周知的原因，SharePoint的附件/圖檔是BLOB的形式，存儲在資料庫中的（我嘗試去資料庫中找這個字段，沒找到）；是以我們隻能用對象模型，當然SPFile是我們第一時間想到的，但是效率可想而知（效率太慢放棄）；是以考慮先将附件/圖檔的Url位址拼接好，插入到Images/Attachment的中間庫中，然後采取WebClient的對象去下載下傳為Byte[]，然後直接上傳，測試結果還是很客觀的，100個附件1分鐘左右（與附件大小有關）。

　　總結：資料遷移過程比較繁雜，需要考慮的東西比較多，前期的規劃很重要，因為資料一旦遷移過去，修修補補會很讓人郁悶，是以對應關系一定一定要先做好，避免後期修改。而且，兩邊系統的開發人員對接非常重要，避免出現少插入字段等現象，造成新系統出問題。基本上就是以上這些，寫出來給有需要的人們參考下，就這樣了。