基線是度量變化的一個參考。基線常常用於醫藥領域。醫生在為病人開藥時，會測量病人的血壓和心率，採集體重或者進行血液檢查。在過了一段時間以後，醫生會重



新採集同樣的資料來觀察什麼指標發生了變化，以便充分評估藥物的影響。


在IT領域，也存在同樣的方式。DBA們也能夠使用基線來衡量計劃或者未計劃的變化的影響。在最好的情況下，這些資料可以用來快速識別那些計劃外的導致效能問題的行為。同時，採集基線最起碼可以讓DBA瞭解當前配置中存在的問題和制定未來的計劃。

使用基線是個好方法，似乎每個DBA都明白它的價值。但不幸的是，還有很多公司並沒有關於資料庫的基線資料。這可能會有兩方面的原因，一個啟動成本，需要大量的時間和精力。如果打算推出自己採集基線的方法，必須對以下問題進行一個思考，並好好回答。

1，你要採集什麼樣的資料？(what)

2，你要在何時採集資料？(when)

3，你會使用什麼方法來採集資料？（what method ，也就是how）

4，你將會把資料存放在哪裡？（where）

5，你從採集的資料裡面怎樣得到資料庫情況報告？（how）

6，你要怎樣長期管理這些採集的資料？（how long）

這些問題需要一些思考並採取相關的對策。不過，似乎很多人常常都是喜歡生活在沒有資料的世界裡，而不是努力去獲取資料。（很多決策都是基於歷史資料而進行的）。

第二個因素是我們自己的被動性。如果對一個DBA問到，“你會採集基線嗎？”，通常的答案是一聲嘆氣，“不會”。造成這樣的原因是很多的，有些DBA會說，手頭有很多工作沒做完；有些DBA會說，整天忙於救火和應對突發事件。歸根到底，都是說沒有時間或者精力來實施新的東西，例如部署採集資料庫基線的方法。當然，也會有的DBA回答說，沒想過主動實施採集基線的策略，因為覺得部署採集基線的活動需要花很多時間和精力，有時候還會吃力不討好。

1，為什麼呢？
最大原因應該是採集基線資料是件比較棘手的事情。DBA可能會意識到基線資料的價值，但是，很多公司並不會去買第三方工具來採集基線資料，因此，很多人都需要手工來採集基線資料。當打打算這樣做的時候，我們也會遇到各種問題：從哪裡開始？自己是否有足夠的時間來進行？採集基線對我有多大幫助？在沒有基線資料時，我已經能夠解決問題了，真的還需要基線資料嗎？

呵呵，這就是關鍵點了：我們真的需要基線資料嗎？我不能很好的回答這個問題，但從每一個有基線資料的資料庫例項來看，基線資料已經證明了其價值。也許，我們會遇到，在我們擁有基線資料時，遇到了一個問題了，但基線資料對該問題沒有參考價值。但，我們也應該換一個角度來考慮，我們是否遇到過沒有可參考資料的情況下來解決問題？如果有參考資料時，我們是否能更快速的解決問題呢？如果有參考資料時，我們是否可以為團隊，為公司創造更大的價值？

事實上，基線資料可以讓DBA的日子過得越來越舒服。因為：

1，你可以發現在某個東西成為一個問題之前發生了什麼改變？
2，更容易排除故障
3，可以更容易的主動進行效能調優
4，可以讓你瞭解當前環境和資料的變化趨勢
5，可以提供更好的容量規劃
。。。
2，該採集什麼呢？
千里之行始於足下，要做一件事情時，可以從最簡單的入手。因為可以採集的資料是很多的，如果不加以規劃和甄別，很容易被海量的資料給淹沒，不僅沒有帶來價值，反而增加了負擔。因此，需要把重點放在哪些資料是最重要的，哪些資料可以幫助我們定位效能問題？同時，也要關注資料庫在哪個時間段比較容易出問題？一般情況下，可以從以下幾方面入手：

1，基本資訊

2，系統使用資訊

3，檔案和資料庫大小資訊

4，Wait 統計資訊

我們從SQL Server的基本資訊開始，因為這些資訊很容易被DBA改變，特別是在有多個DBA的可以訪問SQL Server環境的情況下。經常會遇到某個人修改了某個值（如max memory allocated 或max degree of parallelism），而DBA卻不知道這樣的改變！而隨著虛擬化大潮的來臨，在虛擬化環境下，DBA們更容易遇到如從一個虛擬機器遷移到另外一臺主機時的一些莫名奇妙的問題，而這些通常都是配置問題導致的。

 

如果你知道一些基本效能監控計數器（如CPU，記憶體，磁碟延遲）、資料庫連線和活動等的基線資訊，在發生效能問題時，可以優先檢查這些資料，看能否發現一些問題。特別是如果使用了指令碼，就可以快速的獲取當前的效能資料，並和正常的效能資料比較。最後，如果DBA管理多個數據庫例項，這些對系統使用，安裝異常，預算等的趨勢資訊，在與領導溝通匯報時，會更有用。

 

一旦知道了基本的設定和系統的使用情況，就可以採集檔案和資料庫的增長的基線資料了。一個DBA的主要和最重要的工作之一是，保持系統的可用性。因此，避免資料庫執行的空間不足，採集基線資料是最快捷的方式，也是很重要的方式。最好的做法是通過採集當前的檔案和磁碟的大小，計算出資料增長的趨勢：通過這樣做，會使計劃磁碟空間或資料遷移時變得更加容易。如果系統資料庫中的表的大小異常增長了，DBA可以深入瞭解這個相關的業務，瞭解應用程式是如何使用的，從而排除是否存在問題。

 

最後，除了瞭解CPU，I /O和記憶體的正常值外，還有一個很重要的，是看一個數據庫伺服器裡的等待統計資訊。每個SQL Server例項都有等待統計資訊，而這些資訊可以用於效能調優，通過它，可以瞭解基本的正常的等待統計資訊，在需要的時候，也可以用來進行比較。

3，何時採集
 

一旦已經決定想要什麼樣的資料，必須決定採集的頻率。資料太多，會佔用額外的空間，太少，你不能很好的瞭解資料庫到底發生了什麼。採集的頻率取決於資料本身，例如效能計數器可以每隔15秒。但捕捉事務日誌檔案的大小時，就沒必要以15s作為採集間隔了。

 

另外，你需要確定是否需要檢視最繁忙的時間段或正常營業時間或任何時間的資料。你還必須確定，會保持多久的資料。是否有必要將資料儲存6個月，或一年？也許三個月的資料就足夠了。只有你自己知道自己資料庫的情況並進行管理。同樣，也可以從簡單的開始，這是比較直接的，例如僅在工作時間和捕獲資料，只保留最後3個月的指標進行比較，到時候再根據實際情況，建立其他採集模式或擴大。

4，存放何處
根據經驗，最好是建立一個單獨的資料庫來儲存所有的生產庫例項的基本資訊。最好需要一個共享伺服器來存放基線資料庫，這樣所有生產伺服器上的資料可以被複制然後儲存在基線資料庫。同時應該定期備份該資料庫，和採集，遷移，儲存的指令碼。並把檢視基線資料資訊當成的日常工作必不可少的一部分。

5，下一步
 

本文一系列的四個有關採集基線資料的文章。接下來的三篇文章，將逐步獲得上述的資料採集的過程，並提供指令碼。你的第一個任務是找到一個書庫例項，在這裡你可以建立一個基線資料庫。你的第二個任務是致力於採集這些資料。開始行動吧，騷年？