SQL SERVER 數據庫鏈接服務器總結
因此在SQL SERVER 數據庫服務器上建立到Oracle遠程鏈接服務器。下面就在不同版本中的SQL SERVER上建立連接服務器的經驗作一小結，希望對各位有用。
1、SQL SERVER 2000
SQL SERVER 2000下連接服務器在“安全性”節點下。右鍵點擊“鏈接服務器”——新建，打開連接服務器屬性框。
在鏈接服務器編輯框填寫鏈接服務器的名稱，這是遠程數據庫到本地SQL Server的映射。
服務器類型選擇其它數據庫（SQL SERVER 不做闡述）。到Oracle數據庫的鏈接提供程序有兩種：Microsoft OLE DB Provider for Oracle; Oracle Provider for OLE DB.這兩種提供者有不同的特點，表現在數據鏈接速度上也不同，在此先選擇前者。
產品名稱是作爲鏈接服務器添加的 OLE DB數據源，可自己定義。
數據源是Oracle 數據庫的別名，必須與Oracle數據庫中的數據庫名稱相同。
安全性——選擇用此安全上下文進行：遠程登錄名是登錄Oracle數據庫的登錄名。注意一點，Oracle數據庫中區分大小寫，切記！
密碼當然前些Oracle數據庫的登錄密碼啦！
至此 SQL SERVER 2000下的鏈接服務器已經配置完畢！
SQL SERVER 2000下點擊鏈接服務器可以看到數據表的映射。
檢驗一下：打開查詢分析器： Select * from AAA..BBB.TABLE NAME
AAA爲連接服務器的名稱 BBB爲登錄名。
注意：各個部分最好使用大寫
查詢執行成功（當然您必須已經安裝了Oracle 的客戶端）。
2、SQL SERVER 2005
連接服務器在服務器對象——鏈接服務器下。
設置同在SQL SERVER 2000下差不多，配置好鏈接服務器後，您將得不到數據表的映射。但您可以使用SQL語句進行查詢。
兩種提供者的不同：
//以下摘自巧巧讀書網（http://www.qqread.com/sqlserver/2006/11/f257985.html）
同一機器，同一數據源，同一結果，兩者間還真有不少區別。
首先是速度（連續三次）：
Microsoft OLEDB Provider for Oracle 1分37 1分32 1分30
Oracle Provider for OLEDB 1分10 1分07 1分02
在速度上 Oracle Provider for OLEDB 基本符合 1分3萬條左右，而Microsoft OLEDB Provider for Oracle 1分鐘只有2萬條左右。
照這樣看，答案似乎也就出來了，Oracle Provider for OLEDB也就成了不二選擇。
且慢，我還沒有說明爲什麼選擇25萬條記錄而不是別的數量的數據呢。
這就不得不說說內存的使用：未啓動數據遷移時即停留在VS.Net設計界面時，內存已使用了790M左右，而我機器的物理內存也就896M。
運行開始後，25萬條記錄下Microsoft OLEDB Provider for Oracle 平均在1G左右，而Oracle Provider for OLEDB乖乖得不得了，鐵定在1.25G以上，一次還在1.3G。更離譜的是，原數據表中共有近100萬條記錄，Microsoft OLEDB Provider for Oracle在內存峯值1.5G左右可以順利完成，而Oracle Provider for OLEDB在內存使用一旦突破1.3G往上一些，就開始不停提示內存不足，不在安心的遷移數據了，或者乾脆顯示爲紅色，報一些莫名的錯誤。
這就讓人兩難了，一個速度快了那麼50%，可確是一個內存消耗大戶，有沒有止境，我這破機器也無從得知。
另外一個速度慢，可卻節儉持家，窮人也照顧到了，哈。感覺好這有點像Oracle和MS的企業風格，一個走高端，爲了需要的指標可以不計成本，窮人靠邊；另一個呢，還不錯，雖然也越來越來不鳥沒錢的人，可還做得不太顯眼。
最後了，同樣的數據源（Microsoft OLEDB Provider for Oracle驅動），將目的庫換成SQL Server 2005,驅動爲SQL Native Client,同樣的數據數據轉換，98.9萬條記錄中11.1萬條入庫，靠1分12完事，打開FastLoad，58秒搞定。而且都只是第一次運行，相信如果多運行幾次後，結果應該更好。別說，自家孩子真就不一樣，別人的家的沒法比。 同一機器，同一數據源，同一結果，兩者間還真有不少區別。
首先是速度（連續三次）：
Microsoft OLEDB Provider for Oracle 1分37 1分32 1分30
Oracle Provider for OLEDB 1分10 1分07 1分02
在速度上 Oracle Provider for OLEDB 基本符合 1分3萬條左右，而Microsoft OLEDB Provider for Oracle 1分鐘只有2萬條左右。
照這樣看，答案似乎也就出來了，Oracle Provider for OLEDB也就成了不二選擇。
且慢，我還沒有說明爲什麼選擇25萬條記錄而不是別的數量的數據呢。
這就不得不說說內存的使用：未啓動數據遷移時即停留在VS.Net設計界面時，內存已使用了790M左右，而我機器的物理內存也就896M。
運行開始後，25萬條記錄下Microsoft OLEDB Provider for Oracle 平均在1G左右，而Oracle Provider for OLEDB乖乖得不得了，鐵定在1.25G以上，一次還在1.3G。更離譜的是，原數據表中共有近100萬條記錄，Microsoft OLEDB Provider for Oracle在內存峯值1.5G左右可以順利完成，而Oracle Provider for OLEDB在內存使用一旦突破1.3G往上一些，就開始不停提示內存不足，不在安心的遷移數據了，或者乾脆顯示爲紅色，報一些莫名的錯誤。
這就讓人兩難了，一個速度快了那麼50%，可確是一個內存消耗大戶，有沒有止境，我這破機器也無從得知。
另外一個速度慢，可卻節儉持家，窮人也照顧到了，哈。感覺好這有點像Oracle和MS的企業風格，一個走高端，爲了需要的指標可以不計成本，窮人靠邊；另一個呢，還不錯，雖然也越來越來不鳥沒錢的人，可還做得不太顯眼。
最後了，同樣的數據源（Microsoft OLEDB Provider for Oracle驅動），將目的庫換成SQL Server 2005,驅動爲SQL Native Client,同樣的數據數據轉換，98.9萬條記錄中11.1萬條入庫，靠1分12完事，打開FastLoad，58秒搞定。而且都只是第一次運行，相信如果多運行幾次後，結果應該更好。別說，自家孩子真就不一樣，別人的家的沒法比。