Sql-Server
連結伺服器風險
我正在實現一項新功能，該功能需要來自多個伺服器上的數據庫的數據。我只需要合併所有這些伺服器的數據並對其進行排序。想到的兩個選項是：
- 使用連結伺服器並編寫一個簡單的查詢來合併和排序將從一台伺服器執行的數據並從其他伺服器收集數據。
- 使用應用程序從所有伺服器收集數據，並將其發送回 SQL Server 進行排序（不想在應用程序中實現排序）。
我們在 SQL Server 2008 r2 的主動/主動集群中執行我們的伺服器。所有數據庫都具有相同的權限，如果您可以訪問一個數據庫/伺服器，則您對它們都有權限。這是一個面向公眾的應用程序（需要使用者登錄）。
使用連結伺服器有哪些風險？是否有任何我應該關注的安全漏洞？在活動/活動集群中執行連結伺服器是否有任何問題？與替代方案相比，會有任何重大的性能問題嗎？
關於連結伺服器似乎普遍存在負面“嗡嗡聲”，但我找不到任何具體的東西可以讓我相信那裡有任何真正的擔憂。
只要您考慮了其中的含義，連結伺服器就可以很好地工作：
- 安全性：一個關鍵的考慮因素是，如果您有連結的伺服器，如果其中一個受到威脅，它們都將面臨重大風險。即使您對不同伺服器的每個使用者都有不同的憑據（如果唯一的攻擊向量被洩露/發現/猜測憑據，這將阻止攻擊者獲取其他資源），連結也可以有效地繞過所有這些。該連結還將繞過對公共網路隱藏其他數據庫的保護措施，例如一個或多個伺服器不向公共介面提供數據的情況，因此通常不會通過任何方式通過防火牆可見。您可能會想“好吧，同樣的風險不是複制的問題嗎？” 答案是肯定的，但是複製是在單個應用程序數據庫之間進行的，並且連結的伺服器路由可能會損害同一伺服器上的其他數據庫，因為連結處於伺服器級別而不是數據庫級別（當然，您可以通過仔細控制使用者訪問來減輕這種風險權利，但您至少需要在計劃中意識到這一點）。作為關於安全性的附註：如果伺服器不在同一個站點上，請確保您使用某種形式的 VPN 將它們連結起來，而不是讓 SQL Server 在公共介面上可用。
- 頻寬：如果所有伺服器都在同一個 DC 中，並且它們之間具有良好、快速、不限流量的連接，那麼您可能不需要擔心這一點，但是對於更遠的連接要更加小心，特別是如果您的使用者能夠執行 ad-一些種類的臨時查詢。VPN 鏈路級別的壓縮對於大多數數據集將有很大幫助，但請注意，這將以更大的延遲為代價，這可能會加劇效率問題（見下文）。
- 效率：如果您只是將數據塊拉下線，那麼這不是一個大問題（但請考慮鎖定：請參閱我的下一點），但是一旦您通過連接等方式進行任何操作，就會有限制查詢規劃器可以優化您的請求。如果它需要進行許多索引查找，如果由於網路延遲，伺服器彼此之間不是本地的，則會創建執行非常緩慢的查詢（本地伺服器肯定也存在同樣的問題，但當然程度較小），它可能會改為使用索引掃描（權衡頻寬使用以獲得延遲優勢）佔用頻寬，如果它持有鎖（以避免臟讀問題等），這也會影響應用程序的其他部分。
- 鎖定/並發：離開伺服器會增加查詢的執行時間，這會加劇您可能還不知道的鎖定問題，從而嚴重降低應用程序的並發性和可伸縮性。如果使用正常和/或長時間執行的跨伺服器查詢，您需要非常小心，您需要密切關注鎖定問題並酌情給予規劃器提示。
只要您有足夠的規定來管理安全和性能問題，我不會認為使用連結伺服器有問題，儘管可能有更好/更安全/更可靠/更容易安全的方法來實現相同的目標結果。
我也經歷過同樣的負面“嗡嗡聲”，但我在使用連結伺服器時遇到的唯一問題是您可以輕鬆地通過網路提取大量數據。從 DBA 的角度來看，如果您有非 DBA 可以做到這一點，即使他們承諾不會濫用它，這也是可怕的。
在您的情況下，編寫自己的應用程序似乎沒有任何好處，因為這仍然需要移動數據。聽起來您有一個非常簡單的權限模型，因此根據環境，可能值得設置一些特殊權限，以便在不需要的地方不使用連結。