在SQLServer2008中引入了ResourceGovernor，通過對一些語句的CPU和內存的資源限制瞻性的對多租戶的數據庫環境進行有效管理。這個特性允許客戶實現數據庫的整合或者把數據庫配置為服務管理。但是隨著虛擬化和云技術的發展，IO的控制成為一個難題。在SQLServer2014中，我們根據客戶的請求,增加了對IO資源的控制來解決客戶遇到的問題。

新特性：

• ResourcePools在對CPU/Memory的控制基礎上增加了對卷(pervolumeDiskPartition邏輯分區)的IOPs控制，可以針對卷設置***和最小的IOPS，從而實現更復雜的資源控制。

• 可以對單個磁盤分區設置maximumoutstandingIO(在實例級別).使用這個特性可以更好的調整磁盤子系統的負載。

• 澄清一下byvolume指的是diskvolume被windows文件系統識別的APIs.

• 我們在DMVsys.dm_resource_governor_resource_pools和sys.dm_resource_governor_configuration中新增了欄位可以查詢IO的使用和配置.另外我們新增加了DMVsys.dm_resource_governor_resource_pool_volumes,可以捕獲IO跨不同分區的使用情況。

• 新增加了兩個新的XEvents(file_write_enqueued,file_read_enqueued)，可以對于IO資源管理隊列的IO請求。

• ***我們增加了性能監視指標SQLServer:ResourcePoolStats包括DiskReadIO/sec,DiskReadBytes/sec,AvgDiskReadIO(ms),DiskWriteIO/sec,DiskWriteBytes/sec,AvgDiskWriteIO(ms),DiskReadIOThrottled/sec,DiskWriteIOThrottled/sec等。

•  

如何使用：

讓我們以下面的場景為例說明如何使用IO資源治理在一個SQL服務器實例上控制資源。

假設我們有一臺數據庫主機或者運行在私有云上的整合數據庫，我們需要根據多個客戶的要求放多個數據庫，這樣可以實現資源的有效利用同時節省成本。如果客戶的一個數據庫運行IO密集型的工作負載，這樣會導致整個磁盤的IO性能，從而影響其他用戶的操作。

***個我們會為每個客戶/數據庫創建一個資源池和一個可以將客戶會話映射到對應資源池的分類器函數。例如,會話為客戶1可以被映射到資源池1,會話為客戶2到資源池2。

如果你想使用IO資源治理，重要的是對每一個資源池設定最小或大IOPS,以便IO請求定向到治理子系統。在下面的例子中,我們對每個資源池都設置MAX_IOPS_PER_VOLUME:

--Create2resourcepools&2workloadgroups.
CREATERESOURCEPOOLCustomer1Pool;
CREATERESOURCEPOOLCustomer2Pool;
GO

CREATEWORKLOADGROUPCustomer1GroupUSINGCustomer1Pool;
CREATEWORKLOADGROUPCustomer2GroupUSINGCustomer2Pool;
GO

--Createclassifierfunction
CREATEFUNCTIONfnUserClassifier()
RETURNSSYSNAME
WITHSCHEMABINDING
AS
BEGIN
IFORIGINAL_DB_NAME()='Customer1DB'
BEGIN
RETURN'Customer1Group'
END

IFORIGINAL_DB_NAME()='Customer2DB'
BEGIN
RETURN'Customer2Group'
END

RETURN'default'
END;
GO

--SettheclassifierfunctionandenableRG.
ALTERRESOURCEGOVERNORWITH(CLASSIFIER_FUNCTION=dbo.fnUserClassifier);
ALTERRESOURCEGOVERNORRECONFIGURE;
GO

--SetdefaultvaluesfortheresourcepoolssothatIORGisenabled.
ALTERRESOURCEPOOLCustomer1PoolWITH(MIN_IOPS_PER_VOLUME=0,MAX_IOPS_PER_VOLUME=2147483647);
ALTERRESOURCEPOOLCustomer2PoolWITH(MIN_IOPS_PER_VOLUME=0,MAX_IOPS_PER_VOLUME=2147483647);
ALTERRESOURCEGOVERNORRECONFIGURE;
GO

將每個工作負載分類到不同的資源池有助于我們根據每個用戶的使用情況配置資源限制，同時可以監控用戶的工作復雜。下面的圖(性能監視器)表明由于客戶1的大量IO請求導致了客戶2的性能下降：

為了保護客戶2的性能不受其他客戶的影響，我們對客戶2的資源池設置MIN_IOPS_PER_VOLUME。從上面的圖表,看起來,系統可以處理大約1300IOPS,所以我們決定保留650IOPS給客戶2:

ALTERRESOURCEPOOLCustomer2PoolWITH(MIN_IOPS_PER_VOLUME=650);
ALTERRESOURCEGOVERNORRECONFIGURE;

GO

通過這個配置，SQLServer將會限制其他資源池的負載，從而滿足650IOPS給客戶2.下面的圖中,我們可以看到系統的IOPS被公平的分配到客戶，客戶2的性能沒有受其他客戶的影響。

MIN_IOPS_PER_VOLUMEsetting雖然可以讓資源池保留資源，但是不會限制***的IOPS.這就意味著性能仍然會根據其他客戶的使用情況變化，無法獲得穩定性能。為了避免這個問題,保證可預測的性能，我們需要對每個客戶設置MAX_IOPS_PER_VOLUME。這將對客戶設置***的工作負載限制，一方面可以達到預測的性能，同時還會保護其他的客戶性能不受影響：

ALTERRESOURCEPOOLCustomer2PoolWITH(MAX_IOPS_PER_VOLUME=750)
ALTERRESOURCEGOVERNORRECONFIGURE
GO

通過對IO資源池的資源設定，我們可以控制每個客戶需要的資源。這可以保證性能不會受其他客戶的影響，同時也可以基于用戶的資源請求設定不同的SLA或者數據庫服務。

另一個場景是可以將OLTP工作負載與維護操作進行隔離。比如重建索引是一種常見的操作,因為要掃描整個索引或者表，會導致大量的IO請求。通過使用IO資源治理我們可以限制這些操作的IO復雜，從而保證OLTP的并發和性能不受影響。

可以提供下載downloadingtheSQLServer2014CTP2測試這個功能。

原文來自：http://blogs.technet.com/b/dataplatforminsider/archive/2013/11/07/io-resource-governance-in-sql-server-2014.aspx

譯文鏈接：http://lzf328.blog.51cto.com/1196996/1324689