SQL Server自動化運維繫列——關於數據收集（多服務器數據收集和性能監控）

需求描述

在生產環境中，不少狀況下須要採集數據，用以定位問題或者造成基線。

關於SQL Server中的數據採集有着不少種的解決思路，能夠採用Trace、Profile、SQLdiag、擴展事件等諸多方案。

幾種方案各有利弊，其中從SQL Server2012版本開始，微軟的開始各類整合這些採集方案，力推擴展事件。

對於上述的數據採集只是一種實現手段，對於採集完數據的存儲沒有統一的規範，而且對於多服務器的數據採集及彙總沒造成統一的規範。

本篇實現

一、經過SQL Server自帶的數據採集器實現多服務器的性能採集

二、利用SQL Server數據採集數據倉庫（DW）造成運維報表

三、經過靈活性的配置方式，實現不一樣服務器不一樣採集點的數據收集

<1>基礎配置

之前，有個同事說SQL Server的自動化運維太弱了，而且定位問題也比較麻煩，須要記住各類系統的DMV....各類日誌查找....你看看人家MySQL強大的圖形化界面提示，讓你一眼就能發現當前數據庫所存在的問題。

的確，來看看MySQL所提供的圖形化的運維界面

是他孃的帥氣，把總體的平臺給劃分的很詳細：網絡、實例狀態、存儲狀態。

並且還有看上去很優雅的圖形化展現界面。

上述界面所反映的內容，對於問題的查找是至關便利的，在SQL SERVER中就找不到一樣的模塊。若是有經驗的DBA會經過任務管理器、性能監視器、而後配合系統自帶個一些個DMV...進行分析....看上去複雜而且很高深的樣子。

其實，在SQL SERVER中，也有相似的功能模塊，而且更靈活的實現多臺服務器共同採集，下面，咱們來看一下詳細的使用和配置流程。

在數據收集上，右鍵選擇「配置管理數據倉庫」

 

SQL SERVER爲了可以支撐多臺服務器的數據採集任務，鑑於數據量的龐大和用於數據分析的重要性，因此本身建立了一個用於數據分析的數據倉庫（DW）

這裏選擇好實例，建立好數據倉庫就能夠。

提示：爲了不影響生產系統的性能，通常這裏建議採用另一臺空閒的實例，專門用於數據採集和性能分析。

我這裏演示，就採用本地的實例進行配置，而後下一步：

到這一步是管理數據倉庫的用戶權限，能夠配置用戶權限，三種權限級別：管理員、可讀、可寫；

很簡單，配置完成直接下一步，而後就完成了該數據採集的數據倉庫的搭建。

<2>基礎配置

這一步就是設置數據收集了，簡單點講就是要配置收集的數據項有哪些。

一樣是，數據採集上右鍵，而後選擇「設置數據採集」

而後，下一步就是鏈接數據倉庫，選擇緩存目錄

而後，下一步就能夠完成，這裏SQL SERVER一樣的內置了一套數據蒐集的模板，會爲你收集所有的基本信息，固然，也能夠自定義，文章後面介紹。

來看默認的數據採集的收集項

自帶的默認模板中，分爲了查詢統計信息，其實這個就對應的實例狀態、磁盤存儲、服務器活動，除了這下還贈送了一個實用工具信息，這個是用來靈活配置其它幾個收集項的。

能夠隨時的根據我的喜愛啓動、中止數據收集動做，酌情采用。

而且，也能夠本身配置收集動做的時間間隔或者狀態值。

 

而且，SQL Server貼心的給內置了一下計劃模板，基本涵蓋了全部的應用場景。

而後，你就放心的讓它本身去採集就能夠了。不爽的時候隨時中止就能夠。

剩下來的事就是查看採集數據了，鑑於MYSQL提供瞭如此精美的圖像化展示方式，SQL SERVER一樣也有。

就是它了

看上去是否是也有那麼點意思了，包括：CPU、內存、磁盤IO、網絡...

而且順帶着SQL server等待、SQL語句執行狀況等

而後，針對性能調優的一些語句，也給出了排序包括CPU、運行時間、IO總數、物理讀取、邏輯讀取等

固然，我本地的機器自己採集量就不多，而且運行的T-SQL語句就很少，因此圖表工具顯示的很空曠。

來看看磁盤存儲的

上述內容大致就這些，本身用的時候再行挖掘吧，本篇提供思路。

若是經驗老道的DBA，我估計上述語句經過系統的DMV均可以查看的到，可是那僅限於有經驗的，上述方案爲小白下降了維護數據庫的成本。

而且能夠在多臺服務器中進行採集，集中處理問題。

 

結語 

在本篇介紹利用SQL Server自帶的數據收集工具進行數據庫運維。關於自定義的數據收集項設置，後一篇介紹吧。

另外關於數據收集的DW有不少頗有用的內容，若是對於大型的平臺性能運維，能夠藉此擴展，造成本身的運維平臺。

關於SQL Server自動化運維和檢測的內容很普遍，其中不少都是從平常的經驗中出發，一步步的從手動到自動的過程。

 

若是您看了本篇博客,以爲對您有所收穫，請不要吝嗇您的「推薦」。