Sql-Server
用於 SAN 性能的 SQL Server 2005 標准文件組/文件
我將此送出給堆棧溢出（此處），但意識到它確實應該在伺服器故障上。對於不正確和重複的發布，我們深表歉意：
好的，所以我剛剛參加了 SQL Server 課程，我們討論了多個文件組和文件在本地 RAID 和本地磁碟上使用時的使用場景，但我們沒有觸及 SAN 場景，所以我的問題如下；
我目前有一個在 SQL Server 2005 上執行的 250 gig 數據庫，其中一些表有大量寫入，而另一些則相當靜態。數據庫和所有對象駐留在具有單個數據文件的單個文件組中。日誌文件也在同一卷上。我的解釋是，應該在不同的磁碟上使用單獨的數據文件以減少磁碟爭用，並且應該使用文件組對數據進行分區。但是，對於 SAN，您顯然不會遇到與使用小型 RAID 設置相同的磁碟爭用問題（或者至少我們目前沒有），並且標準版不支持分區。
那麼為了提高並行性我應該怎麼做呢？
我對各種 Microsoft 出版物的理解是，如果我增加數據文件的數量，則單獨的執行緒可以分別在每個文件上執行。這讓我想到了我應該擁有多少個文件的問題。每個核心一個？我是否應該將具有高活動水平的表和索引放在單獨的文件組中，每個文件組的數據文件數量與我們擁有的核心相同？
謝謝
- 每個文件組都應該有 X 個數據和日誌文件，其中 X 是任務管理器可見核心的數量 - 這允許優化 IO 行為。
- 這對於 tempdb 尤其重要 - 當分配/釋放擴展區（8 頁的組）時，文件有時會完全鎖定 SQL Server。Tempdb allcoates 很多對象。
- 為多張磁碟分發只對更好的 IO 有意義。一個好的 SAN - 可能會使驅動程序的出色 IO 功能飽和（隊列長度通常最大為 256 PER DISC），因此一個好的 SAN 可能需要多個磁碟來保持足夠的 IO 以充分利用它。
- 但即使沒有良好的 SAN，多個文件也可以避免在進行插入等操作時訪問單個文件的瓶頸。
- 超過上面提到的 X 是沒有意義的——因為每個核心最多可以在給定時間執行一個執行緒。ALlocation 是原子的，因此每個核心在執行此操作時都不會切換執行緒。但是 X 核心可能都想同時擴展 ;)
- 同樣重要的是：正確格式化光碟。確保（2008 年之前的伺服器）分區對齊，確保使用 64kb 節點大小格式化磁碟 - 否則您可能會浪費多達 40% 的 IO 性能。
- 分區根本不會進入這個遊戲；）