我們在 SQL Server 2016 上有一個 1.5tb 的聚集列存盤表，900 個磁區。
我們在 2012 盒子上創建了一個鏈接服務器，指向該服務器。
執行一個簡單的“從 servera.databasea.dbo.tablea 中選擇 fielda、fieldb、fieldc，其中 partition_field = b 和 otherfield = c”需要 63 秒。
我在兩者上都有系統管理員，所以我有權獲得統計資訊，但是當我運行查詢時 sp_whoisactive 顯示它正在運行dbcc show_statistics(@qtbl, @statname) with stat_header join density_vector（據我們所見）正好 60 秒，然后才更改為執行查詢，此時它完成3 秒。
因此，每個鏈接服務器查詢至少需要 60 秒。我嘗試使用“SQL Server”和 Microsoft OLE Provider for SQL Server 構建鏈接服務器，兩者都做同樣的事情。有沒有辦法解決這種行為？是的，我們將在接下來的幾個月內離開 2012 年，但在那之前我們有一些緊迫的資料需求。我們的后備方案是復制我們需要的資料范圍，但這可能會變得很難看。
鏈接服務器（而不是 openquery）的原因是為了最大限度地減少我們需要進行的代碼更改量 - 如果我們可以只在該表上指向一個視圖，那么不需要更改其他代碼。
Collat??ion Compatible 設定為 true，Data Access 設定為 true，RPC 和 RPC Out 設定為 true。
謝謝。
uj5u.com熱心網友回復：
您可以簡單地將 OPENQUERY 版本放在視圖中。
CREATE VIEW dbo.whatever AS
SELECT cols FROM OPENQUERY(...);
OPENQUERY()本質上是在做你會做的事情，如果你：
- 在鏈接服務器上本地運行查詢
- 用過的
servername.databasename.sys.sp_executesql @sql
在這些情況下（我知道這對您來說不是可行的選擇），我不相信您會看到 DBCC 命令正在運行。
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/466130.html