程式師世界 >> 數據庫知識 >> 其他數據庫知識 >> MSSQL >> 若何在SQL Server 2014頂用資本調控器壓抑你的存儲？

若何在SQL Server 2014頂用資本調控器壓抑你的存儲？

編輯：MSSQL

若何在SQL Server 2014頂用資本調控器壓抑你的存儲？。本站提示廣大學習愛好者：（若何在SQL Server 2014頂用資本調控器壓抑你的存儲？）文章只能為提供參考，不一定能成為您想要的結果。以下是若何在SQL Server 2014頂用資本調控器壓抑你的存儲？正文

在明天的文章裡，我想談下SQL Server 2014裡異常酷的晉升：如今你終究可以依據須要的IOPS來壓抑查詢！資本調控器（Resource Governor）自SQL Server 2008起引入，但供給的功效照樣有所限制：你只能限制CPU時光（這個曾經很棒了），還有你能限制查詢（從每一個自力的查詢）內存量。

但作為DBA的你，你常常會停止一些數據庫保護操作，例如索引重建，DBCC CHECKDB操作等。我們都曉得，這些操作會在你的存儲裡帶來年夜量的IOPS直至峰值。假如在7 * 24在線的數據庫來講，這個會影響你的臨盆力，給營業和發賣額帶來很年夜影響。

自SQL Server 2014開端，這個情形就變了，由於你可以經由過程資本調控器來安排指定的資本池來限制IOPS應用率。當你隔離你的DBA操作到指定的資本池時，你能指定資本池可使用的最年夜IOPS（包含最小IOPS）。是以你可以壓抑下DBA操作須要的IOPS。你的臨盆任務量便可以更好的應用你的存儲。更多信息可以檢查微軟在線贊助。

我想用一個異常簡略的例子來展現下這個行動。假定你是DBA，正要停止慣例索引重建操作，這個須要經由過程資本調控器對它們的最年夜IOPS應用率停止掌握。第1步我們為DBA操作創立公用的資本池和任務負荷組。

-- Create a new Resource Pool for the DBAs.
-- We use a very high value for MAX_IOPS_PER_VOLUME so that we are
-- currently running unlimited.
CREATE RESOURCE POOL DbaPool WITH
(
 MAX_IOPS_PER_VOLUME = 100000
 )
GO

-- Create a new Workload Group for the DBAs
CREATE WORKLOAD GROUP DbaGroup
USING DbaPool
GO

從適才的代碼可以看到，CREATE RESOURCE POOL語句如今為你供給MAX_IOPS_PER_VOLUME屬性（包含MIN_IOPS_PER_VOLUME）。這裡我設置了一個很高的值，是以在第一次履行時IOPS不會受限，這裡我們依據須要的IOPS樹立了初始基線。下一步我會創立資本調控器須要的分類函數。

-- Create a new Classifier Function for Resource Governor
CREATE FUNCTION dbo.MyClassifierFunction()
RETURNS SYSNAME WITH SCHEMABINDING
AS
BEGIN
DECLARE @GroupName SYSNAME
 
IF SUSER_NAME() = 'DbaUser'
BEGIN
SET @GroupName = 'DbaGroup'
END
ELSE
BEGIN
SET @GroupName = 'Default'
END
 
RETURN @GroupName;
END
GO

在分類函數裡我們依據登錄停止評價。假如登錄是DbaUser，進入的會話會在DbaGroup任務負荷組裡。不然就進入默許的任務負荷組。最初我們在資本調控器注冊並設置裝備擺設它，如許我們的設置就失效了。

-- Register the Classifier Function within Resource Governor
ALTER RESOURCE GOVERNOR WITH
(
 CLASSIFIER_FUNCTION = dbo.MyClassifierFunction
 )
GO

-- Reconfigure Resource Governor
ALTER RESOURCE GOVERNOR RECONFIGURE
GO

如今當你創立名為DbaUser的登錄時，你可以用它銜接到你的SQL Server。你可以在DMV sys.dm_exec_sessions 看下 group_id列驗證下到來的會話能否在准確的任務負荷組裡。下一步我在ContoRetailDW數據庫的FactOnlineSales內外的DataKey裡創立一個非集合索引。

-- Create a simple Non-Clustered Index
CREATE NONCLUSTERED INDEX idx_DateKey ON FactOnlineSales(DateKey)
GO

我們從開端就創立了資本池，如今在我們在我們的資本池裡並沒無限制。是以當我們如今停止適才創立的非集合索引的索引重建時，SQL Server會占用年夜量的IOPS。我們可以經由過程機能監控裡的“SQL Server:Resource Pool Stats:Disk Write IO/Sec”機能計數器來驗證適才創立的資本池。

ALTER INDEX idx_DateKey ON FactOnlineSales REBUILD
GO

可以看到索引重建消費近100的IOPS。接上去我要做的是限制DbaPool資本池為僅50的IOPS：

-- Let's change the Resource Pool by lowering the maximum IOPS.
ALTER RESOURCE POOL DbaPool WITH
(
 MAX_IOPS_PER_VOLUME = 50
 )
GO

如今當你履行索引重建時，在機能監督器裡可以清晰看到，在特定的資本池裡只要均勻50 IOPS。

別的Disk Write IO Throttled/sec機能計數器也會告知為你資本調控器的IOPS的限制數。

應用之前的資本調控器，查詢自己毫無方法，它能否被壓抑了。這對機能調優也是個異常主要的身分。當啟用資本調控器時，沒有特定的期待類型湧現在SQL Server裡。我的測試顯示一旦資本調控器啟用時，有更多的PAGEIOLATCH_SH/PAGEIOLATCH_EX期待類型，這就對了。上面2個圖片顯示了關於產生索引重建的會話裡詳細的期待類型信息——第1個沒有資本調控器，第2個有資本調控器壓抑了IOPS。