看了標題還是一頭霧水？嗯，我也是。

我剛剛開始為新雇主擔任 DBA 的新工作，並且遇到了一些安裝 SQL Server 的創造性方法。我以前使用 SQL Server 的經驗都是基於在虛擬或物理硬體上執行的單個 MSSQLSERVER 實例。我們過去常常避免 SQL Server 的多實例安裝，只是為了讓一切都真正分離和簡單。

在我的新雇主那裡，他們在一個虛擬硬體上捆綁了相當多的 SQL Server 標準版實例。他們的（好吧，我想我現在應該稱之為，我們的……）推理：

• 在一個（虛擬）硬體上擁有多個 SQL Server 實例可以減少整個環境中的 SQL Server 數量和許可成本。

我還沒有發現這種配置背後的任何其他原因。

絕對沒有可用性組或事務複製正在進行，事務日誌傳送尚未實現。

伺服器已配置為具有預設實例和多個附加實例，如下所述。

SQL Server 環境

SQL Server 配置為包含多個實例。

伺服器到實例的關係

每個 SQL Server 可以有 1 到n 個實例

SQL_SERVER_01 (Standard Edition SQL Server)
\ MSSQLSERVER (default instance)
\ VARIOUS_INS (the 2nd instance)
\ SOMETHINGNW (the 3rd instance)
\ A_NAMEGIVEN (the 4th instance)
\ INSTANCENEW (the xth instance) 

實例 | 智慧財產權 | 港口 | 別名 (CNAME)

每個實例都與一個 IP 地址相關，每個 IP 地址都有一個單獨的別名 (CNAME)，以便 SQL Server 始終可以偵聽埠 1433。這簡化了防火牆配置，因為只需為預設 SQL Server 埠添加規則. 嗯。

MSSQLSERVER | 10.0.0.22 | 1433 | SQL_SERVER_01_I00
VARIOUS_INS | 10.0.0.23 | 1433 | SQL_SERVER_01_I01
SOMETHINGNW | 10.0.0.24 | 1433 | SQL_SERVER_01_I02
A_NAMEGIVEN | 10.0.0.25 | 1433 | SQL_SERVER_01_I03
INSTANCENEW | 10.0.0.26 | 1433 | SQL_SERVER_01_I04

因此，對於在同一虛擬伺服器上執行的每個 SQL Server 實例，網路團隊必須為虛擬 NIC 提供一個 IP 地址，並為實例的 IP 地址創建一個 CNAME/Alias。必須為每個虛擬 NIC 配置正確的 IP 地址，並且必須為每個實例的 IP 地址正確配置 SQL Server 配置（偵聽此 IP 地址，為此 IP 地址啟動，……）。SQL Server 不會響應典型的 SERVER\INSTANCE 表示法，這意味著伺服器只能通過 Alias/CNAME 訪問（例如 SQL_SERVER_01_I00）

（虛擬）硬體

在我忘記之前，我認為讓您了解為此類 SQL Server 實例配置的典型虛擬硬體可能是一個好主意。

磁碟

虛擬磁碟在 VMware 中預先配置並附加到 SQL Server。一些硬體供應商在後台。可能是 IBM，可能是日立，…. MDF 文件的磁碟和 LDF 文件的磁碟。

處理器

是的，多個處理器。在此範例中，四個邏輯處理器 @2.9 GHz

記憶

這台伺服器只有 32GB。每個 SQL Server 實例都配置為消耗 1GB 到 4GB 的記憶體。例如，該伺服器有 6 個實例，每個實例包含 1 … 10 個數據庫，大小從 100 MB 到幾 GB 不等。沒什麼大不了的。

SQL Server 實例配置

每個 SQL Server 實例將按如下方式配置。

最大並行度

預設 (0)

記憶

最小記憶體將設置為 256 MB，最大記憶體將設置為 1GB 到 4GB。

親和麵具

未配置。

最大並行度的成本

預設 (5)

我的想法

根據我的經驗，我了解到，在配置設置和分析問題時，最好使用單個實例。但這似乎不是一個選擇。所以沒必要從那個方向開始討論。我知道。

我認為只有 4 個邏輯處理器和所有 7 個實例的 MAX_DOP 設置為 0 並且後台的多個數據庫是一個壞主意。如果一個系統滯後，那麼它們都會嚴重滯後。

問題

看到你了解我的環境，我猜有人會有類似的配置，並且能夠為我提供一些腳本來分析所有內容，或者能夠為我指出正確的建議方向。

開始：

1. 考慮到我目前只有 4 個邏輯處理器用於 6 個實例並且 MAX_DOP 設置為 0，我是否應該每個實例至少有一個邏輯處理器？
2. 如果每個實例有一個邏輯處理器，我應該將 MAX_DOP 保留為 0 還是將每個實例限制為 MAX_DOP = 1？
3. 既然它是標準版，我應該將 MAX_DOP 限制為 4 作為替代方案嗎？

我並不著急，我確實有一些時間可以消磨。我只是好奇是否有人和我有同樣的情況，以及你/他們是如何處理這種情況的。

謝謝你的時間。

1. 考慮到我目前只有 4 個邏輯處理器用於 6 個實例並且 MAX_DOP 設置為 0，我是否應該每個實例至少有一個邏輯處理器？

這取決於每個實例平均使用多少 CPU？您可以從正在執行的預設執行狀況會話擴展事件（假設 2008+）中獲取此資訊。

四個邏輯處理器可能完全適合此工作負載 - 直到我們有數據我們才會知道。話雖如此，由於 SQL Server 的每個實例都是獨立執行的，並且不知道安裝了其他實例，所以我確信 Windows 對交換執行緒不太滿意。

我會查看我的等待統計 dmv，看看我們在 signal_wait 部分是否有更高百分比的等待時間，這表明調度問題和實例之間可能的爭用。此外，我會通過 cpu 上下文切換來查看是否與實例執行狀況的“糟糕時間”和“良好時間”之間存在弱或直接的相關性。

不過，我的直覺告訴我，除非這些是嚴重未充分利用的實例，否則該伺服器必然會出現問題——無論它們是現在發生還是幾個月後發生。

2. 如果每個實例有一個邏輯處理器，我應該將 MAX_DOP 保留為 0 還是將每個實例限制為 MAX_DOP = 1？

MAXDOP 只是限制單個並行查詢在執行期間可能使用的邏輯處理器（“調度程序”）的數量。沒有什麼可以阻止 SQL Server 執行多個並行查詢；事實上，對於那些甚至不知道他們有調度問題的地方（它被視為“阻塞”問題），我已經多次診斷並解決了這個問題。

將 MAXDOP 設置為 1 實質上使所有使用者查詢成為單執行緒的。同樣，這不會阻止 SQL Server 一次執行多個任務，因為它只是強制串列執行。這意味著每個實例都有四 (4) 個可見的線上調度程序，總共有4x 個實例*可能的並發查詢。在這裡設置 MAXDOP 並不能解決邏輯上負擔過重的問題，沒有考慮到虛擬伺服器的實際設置是否可以在超執行緒（如果啟用）核心上執行。哎呀。

我並不是說強制 MAXDOP 為 1 是好是壞，只是我們沒有數據可繼續。因此，我們不會知道設置的影響。不過，再一次，我絕對不會將其設置為四 (4)！

3. 既然是標準版，我是否應該將 MAX_DOP 限制為 4 作為替代方案？

嗯，它不能高於四 (4)，所以它已經是有限的。我相信這個問題與上述問題密切相關。希望我已經將其解釋到令人滿意的理解水平。

如果您想了解正在並行化多少查詢（由於並行度的門檻值較小），您可以查看執行計劃 dmv。這是一項相當昂貴的操作，因此請在所有實例之間的下班時間或幾乎沒有使用的時間進行。請記住，由於伺服器的共享性質，您對一個實例所做的事情將（大致）對所有實例都完成。

引用自：https://dba.stackexchange.com/questions/131050