如何在SQL Server 2014中用資源調(diào)控器壓制你的存儲，相信很多沒有經(jīng)驗的人對此束手無策，為此本文總結(jié)了問題出現(xiàn)的原因和解決方法，通過這篇文章希望你能解決這個問題。

創(chuàng)新互聯(lián)建站是一家專業(yè)從事網(wǎng)站建設(shè)、網(wǎng)站制作的網(wǎng)絡(luò)公司。作為專業(yè)網(wǎng)站建設(shè)公司,創(chuàng)新互聯(lián)建站依托的技術(shù)實力、以及多年的網(wǎng)站運營經(jīng)驗,為您提供專業(yè)的成都網(wǎng)站建設(shè)、營銷型網(wǎng)站建設(shè)及網(wǎng)站設(shè)計開發(fā)服務(wù)！

在今天的文章里，我想談下SQL Server 2014里非常酷的提升：現(xiàn)在你終于可以根據(jù)需要的IOPS來壓制查詢！資源調(diào)控器（Resource Governor）自SQL Server 2008起引入，但提供的功能還是有所限制：你只能限制CPU時間（這個已經(jīng)很棒了），還有你能限制查詢（從每個獨立的查詢）內(nèi)存量。

但作為DBA的你，你經(jīng)常會進行一些數(shù)據(jù)庫維護操作，例如索引重建，DBCC CHECKDB操作等。我們都知道，這些操作會在你的存儲里帶來大量的IOPS直至峰值。如果在7 * 24在線的數(shù)據(jù)庫來說，這個會影響你的生產(chǎn)力，給業(yè)務(wù)和銷售額帶來很大影響。

自SQL Server 2014開始，這個情況就變了，因為你可以通過資源調(diào)控器來部署指定的資源池來限制IOPS使用率。當你隔離你的DBA操作到指定的資源池時，你能指定資源池可以使用的較大IOPS（包括最小IOPS）。因此你可以壓制下DBA操作需要的IOPS。你的生產(chǎn)工作量就可以更好的使用你的存儲。更多信息可以查看微軟在線幫助。

我想用一個非常簡單的例子來展示下這個行為。假設(shè)你是DBA，正要進行常規(guī)索引重建操作，這個需要通過資源調(diào)控器對它們的較大IOPS使用率進行控制。第1步我們?yōu)镈BA操作創(chuàng)建專用的資源池和工作負荷組。

-- 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 DBAsCREATE WORKLOAD GROUP DbaGroupUSING DbaPoolGO

從剛才的代碼可以看到，CREATE RESOURCE POOL語句現(xiàn)在為你提供MAX_IOPS_PER_VOLUME屬性（包括MIN_IOPS_PER_VOLUME）。這里我設(shè)置了一個很高的值，因此在第一次執(zhí)行時IOPS不會受限，這里我們根據(jù)需要的IOPS建立了初始基線。下一步我會創(chuàng)建資源調(diào)控器需要的分類函數(shù)。

-- Create a new Classifier Function for Resource GovernorCREATE FUNCTION dbo.MyClassifierFunction()RETURNS SYSNAME WITH SCHEMABINDINGASBEGINDECLARE @GroupName SYSNAME IF SUSER_NAME() = 'DbaUser'BEGINSET @GroupName = 'DbaGroup'ENDELSEBEGINSET @GroupName = 'Default'END RETURN @GroupName;ENDGO

在分類函數(shù)里我們根據(jù)登錄進行評估。如果登錄是DbaUser，進入的會話會在DbaGroup工作負荷組里。否則就進入默認的工作負荷組。最后我們在資源調(diào)控器注冊并配置它，這樣我們的設(shè)置就生效了。

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

-- Reconfigure Resource GovernorALTER RESOURCE GOVERNOR RECONFIGUREGO

現(xiàn)在當你創(chuàng)建名為DbaUser的登錄時，你可以用它連接到你的SQL Server。你可以在DMVsys.dm_exec_sessions看下 group_id列驗證下到來的會話是否在正確的工作負荷組里。下一步我在ContoRetailDW數(shù)據(jù)庫的FactOnlineSales表里的DataKey里創(chuàng)建一個非聚集索引。

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

我們從開始就創(chuàng)建了資源池，現(xiàn)在在我們在我們的資源池里并沒有限制。因此當我們現(xiàn)在進行剛才創(chuàng)建的非聚集索引的索引重建時，SQL Server會占用大量的IOPS。我們可以通過性能監(jiān)控里的“SQL Server:Resource Pool Stats:Disk Write IO/Sec”性能計數(shù)器來驗證剛才創(chuàng)建的資源池。

ALTER INDEX idx_DateKey ON FactOnlineSales REBUILDGO

可以看到索引重建花費近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

現(xiàn)在當你執(zhí)行索引重建時，在性能監(jiān)視器里可以清楚看到，在特定的資源池里只有平均50 IOPS。

另外Disk Write IO Throttled/sec性能計數(shù)器也會告訴為你資源調(diào)控器的IOPS的限制數(shù)。

使用以前的資源調(diào)控器，查詢本身毫無辦法，它是否被壓制了。這對性能調(diào)優(yōu)也是個非常重要的因素。當啟用資源調(diào)控器時，沒有特定的等待類型出現(xiàn)在SQL Server里。我的測試顯示一旦資源調(diào)控器啟用時，有更多的PAGEIOLATCH_SH/PAGEIOLATCH_EX等待類型，這就對了。下面2個圖片顯示了對于發(fā)生索引重建的會話里具體的等待類型信息——第1個沒有資源調(diào)控器，第2個有資源調(diào)控器壓制了IOPS。

2個運行的測試有巨大的區(qū)別，尤其是在PAGEIOLATCH_EX和SOS_SCHEDULER_YIELD等待類型。

從我站在IOPS壓制來看，對于已有的功能來說，資源調(diào)控器是個很好的附加，這讓資源調(diào)控器更加成熟。

大家可以嘗試用這個新功能解決IOPS方面的問題。

看完上述內(nèi)容，你們掌握如何在SQL Server 2014中用資源調(diào)控器壓制你的存儲的方法了嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝各位的閱讀！

當前標題：如何在SQLServer2014中用資源調(diào)控器壓制你的存儲-創(chuàng)新互聯(lián)
當前地址：http://www.rwnh.cn/article12/igegc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供ChatGPT、網(wǎng)站改版、服務(wù)器托管、電子商務(wù)、網(wǎng)站內(nèi)鏈、品牌網(wǎng)站設(shè)計

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)