SQL Server 急救包(First Responder Kit)入门教程
如果你的SQL Server數據庫運行起來十分緩慢甚至逐漸停止了,恰巧又趕上了你的數據庫管理員在休假,你又不知道該如何是好,那么這篇文章會幫助你從學習使用SQL Server急救包(SQL Server First Responder Kit)開始解決問題。這個開源項目包含了一系列能夠幫助數據管理員或者臨時數據管理員的腳本,能夠修復和調整SQL Server實例至正常狀態。
這些腳本以存儲過程(stored procedures)的形式安裝在你的服務器的“主”(master)數據庫中。它們都以 “sp_” 為前綴,這能夠保證它們在你所能看到任何一個數據庫中都能被調用。
注意:SQL Server總是首先搜索主數據庫中以 “sp_” 開頭的存儲過程,因此如果標準的存儲過程,即特定數據庫的存儲過程使用那個前綴的話,會略微影響服務器的速度,因為它被放在了錯誤的位置。
sp_BlitzWho: 是誰引起了當前的問題?
當數據庫出錯的時候你首先應該使用這個工具。它會告訴你誰被連接了,它們正在執行什么,并且會告訴你它們拖慢數據庫的程度。
如果你發現了一個需要被關閉的無響應的程序,你可以使用 “kill” 命令加上相關的會話 id 來殺掉它。
如果問題還沒有解決,那么你可以試試sp_BlitzFirst。
sp_BlitzFirst: 你在等待什么?
sp_BlitzFirst工具能幫助你發現你的數據庫在等待什么。在下面的例子中你能看到 #1 問題除了SQL Server消耗了太多的 CPU 時間之外,還有其他的許多問題。
除非你在一個開發者的機器上來測試腳本,否則這些診斷信息真的很不常見。常見的是你會發現一個或更多的 “等待狀態(wait stats)” 問題。
在SQL Server中,所有可能減慢一條查詢的速度的都被追蹤為“等待狀態(wait stats)”。它包括硬盤等待、網絡I/O等待和列粒度上或表粒度上的鎖等待以及等待CPU或者內存資源等等。輸出列表中的鏈接會幫助你處理常見的等待類型,但是它能追蹤上百種不同的等待類型,其中的一些影響系統性能的特定等待狀態就不那么容易能找到相關信息了。
sp_Blitz: 這個數據庫配置正確了嗎?
當你第一次接管了一臺數據庫服務器時,你應該用到的工具就是sp_Blitz。這個工具能夠以配置數據庫的方式識別出一些常見的問題。每一個檢查到的問題都包括如何解決這個問題的信息和一個優先級,這個優先級指明了該以怎樣的順序解決這個問題。
從上邊的圖片你能看到,有許多數據庫長時間沒有備份或者長時間沒有進行崩潰檢查。
它能檢測到的問題還包括:
不良配置,尤其是“由默認引起的錯誤(wrong by default)”,例如并行查詢閥值(cost threshold for parallelism)的默認配置錯誤。
危險文件位置,例如在系統盤上存儲事務日志。
非生產許可證(Non-production licenses)的使用。
對數據庫崩潰、內存不足等警告的忽略。
通用安全設置錯誤,例如錯誤的數據庫所有者權限。
sp_BlitzCache: 哪些條查詢需要進行調整?
如果當前的問題都已經解決了,你就可以開始探索一些主動提高性能的方法了。一個叫做sp_BlitzCache的工具就是用于此的。這個工具用于監控SQL Server的查詢計劃緩存(query plan cache),它能監測哪些查詢對數據庫超時有最大的影響。它也能警告你一些查詢中的常見問題,例如通過標量運算和隱式類型轉換來進行列計算。
sp_BlitzFirst和sp_BlitzCache最主要的區別就是sp_BlitzFirst監測的是實時發生的事件。相反的是,sp_BlitzCache監測的是歷史數據,它能幫你識別出一個趨勢,因此它不需要你當場找出存在問題的查詢操作。
sp_BlitzIndex: 我的索引都是怎么工作的?
如果性能問題看起來是系統性的,而不是針對特定的查詢,你需要檢查的下一個地方就是索引了。索引丟失會造成嚴重的性能問題是眾所周知的,它會造成查詢時間呈十倍、百倍甚至千倍的增長。
一個同樣重要的問題是過多的索引。除了告訴你丟失的索引外,sp_BlitzIndex也會告訴你有可能在維護一個索引上花費的時間比使用它花費的時間還要長。不必要的索引維護不僅會減慢寫入速度,還會產生除緩存以外的更多的數據,這些都會大大減慢不相關查詢的速度。
SQL Server急救包最早由Brent Ozar Unlimited開發,現在它已經是通過MIT協議的一個開源項目了。
總結
以上是生活随笔為你收集整理的SQL Server 急救包(First Responder Kit)入门教程的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Visual Studio 2017将于
- 下一篇: Azure SQL的DTU和eDTU到底