驅動器與安裝點？
以前的高級 DBA 為整個公司的每個 SQL Server 上的所有驅動器設置了掛載點。新的高級 DBA對掛載點想要改變我們的標準感到恐懼（我認為主要是因為他沒有使用它們的經驗）。
根據大量網際網路搜尋的結果，我找不到任何（SQL Server 2000 後）不使用掛載點的理由。
有人知道 Windows 作業系統關於這個主題的限制嗎？
- 我最近經常聽到“作業系統無法辨識掛載點”的說法。（不真實，基於我對我們使用的 Windows Server 版本的研究）。
是否有任何基於證據或經驗的理由不將掛載點與 SQL Server 一起使用？
- 假設驅動器號用完對我們來說不是問題。
據我了解，掛載點對於隔離工作負載非常有用。
任何人都可以確認或反駁我的理解，即掛載點實際上隔離/隔離不同類型的數據和日誌文件（系統數據庫文件、使用者數據庫文件、tempDB）的工作負載比每個驅動器更有效地用於數據文件、日誌文件和 tempdb ?
這取決於掛載點的另一端是什麼。如果掛載都是分佈在相同物理驅動器上的 LUN，則沒有收益。如果 LUN 都在共享的、緩慢的 iSCSI 通道上，則可能沒有收益。如果 LUN 都在 1 個控制器之下……你會看到有多少變數在起作用。沒有一個答案。
要確定掛載點的配置，請參閱Boe Prox 的使用 PowerShell 定位掛載點。
SQL Server的安裝點沒有問題。這些是在作業系統級別定義的，SQL Server“不知道1 ”，它們與它們看起來安裝的驅動器不是同一個卷。
但是，某些監控工具可能會根據最後一句話為您提供不良資訊。
例如，如果您有三個掛載點，例如
C:\SQLData\SQL_Data所有 .MDB 文件的儲存位置C:\SQLData\SQL_Logs所有 .LDF 文件的儲存位置C:\SQLData\SQL_Backups儲存所有 .BAK 和 .TRN 備份文件的位置然後 SQL Server 將毫無問題地工作。但是，如果您執行某種工具在磁碟空間不足時向您發出警告，它可能會檢查 C:而不是它下面的已安裝卷，因此您可能不知道這些安裝點何時磁碟空間不足。此外，各種“最佳實踐”查詢會拋出錯誤警告，告訴您不應將數據、日誌和備份都放在同一個磁碟上，因為*SQL Server 認為它們位於同一個磁碟上。*這些是錯誤的標誌，可以忽略。
但是您基本上需要在伺服器監控中設置一些額外的步驟，以確保 C: 驅動器有足夠的空間並且每個安裝點也有足夠的空間。
我在 SQL Server 中使用掛載點的時間是我遇到的唯一問題：SQL Server 系統執行狀況報告提供了有關可用空間的虛假數據，以及表明您不應該擁有所有數據的虛假錯誤在同一個驅動器上。由於您知道這些是錯誤錯誤，因此它們很容易被忽略。
1 SQL Server 有數據使其知道掛載點，但從實際使用的角度來看，行為沒有區別。它“正常工作”，信任作業系統來處理細節。就像它信任作業系統來處理作為本地驅動器連接的 iSCSI LUN 的細節一樣。
除了 CM_Dayton 的回答和 Sean Gallardy 的回答之外，Mount Points 尚未確定的一個問題與安全性有關。引用在裝載點文件夾上設置 SQL 權限的指南：
儘管掛載點根文件夾可能看起來像正常文件夾並且以與訪問文件夾相同的方式訪問，但它們不是正常文件夾。因此，當您在裝載點根文件夾上設置權限時，權限不會像正常文件夾那樣從“父卷”繼承。事實上，它們根本不是遺傳的。這是因為雖然掛載的捲看起來是“父卷”的子卷，但它不是。您只是通過“父卷”的路徑訪問已安裝的捲。
簡而言之，如果要使用掛載點根文件夾，則必須以不同的方式為掛載文件夾分配權限。您不必像對普通文件夾那樣分配權限，而是必須在卷上分配權限。同樣，來自同一篇文章（重點是微軟的）：
陷阱
不幸的是，仍然可以通過 Windows 資源管理器設置/查看掛載點根文件夾的權限，這可能會導致意外結果，因為掛載點根文件夾的權限可能看起來有效，並且您可以看到“正確的”繼承權限，但是這些不是應用於已安裝卷的權限。
指導方針
- 建議您不要將任何文件直接放在掛載點根文件夾中。這將使權限管理更加簡單，因為傾向於始終檢查文件夾權限，這在這種情況下會產生誤導。相反，在掛載點根文件夾下創建一個子文件夾，並為該子文件夾設置適當的權限。由於子文件夾是普通文件夾，所以你觀察和設置的文件夾權限確實是被應用的權限。因此，使用前面的範例，您需要創建一個新文件夾：D:\FolderForVol3SubfolderXYZ。現在，像往常一樣針對新的SubfolderXYZ文件夾設置文件夾權限。
- 如果您絕對必須將項目直接放在掛載點根文件夾中（不是推薦的方法），那麼您將需要設置卷權限，而不是文件夾權限。回想一下，這是因為掛載點根文件夾權限不是實際在掛載卷上設置的權限（因為掛載點根文件夾不是真正的文件夾）。您可以按如下方式設置卷權限：
* Start->run->diskmgmt.msc (查看卷的屬性 http://technet.microsoft.com/en-us/library/cc740097.aspx ) * 選擇卷->屬性->安全選項卡 3. 如果要添加新文件夾以供 SQL 使用，請注意 SQL 訪問所需的權限：
* 從 SQL Server 2012 開始，權限被分配給每個服務的每個服務 SID。 http://msdn.microsoft.com/en-us/library/jj219062.aspx * 配置 Windows 服務帳戶和權限 http://msdn.microsoft.com/en-us/library/ms143504.aspx
如果您不想按照 MS 的建議將所有內容嵌套在 Mount Point 下的子文件夾中，我發現最容易分配權限的方法是通過該**
cacls.exe**實用程序。有關它的詳細說明，請參見在 Windows Server 2003 中無法對 NTFS 文件系統卷的根目錄應用權限。我認為這還不是一個完全解決的問題。這個最近的問題SQL Server FCI installation with Mount Point 權限問題表明它仍然可以在帶有 SQL Server 2016 的 Windows 2012 上發生。
根據您要分配的安全性，命令可能會有所不同，但測試是成功的關鍵，因此在針對實時掛載點執行命令之前要熟悉該命令，因為如果您忘記了像
\E標誌這樣簡單的東西，您可以快速破壞安全性。