[轉]2年SQL Server DBA調優方面總結

 

2年SQL Server DBA調優方面總結

當2年dba 我以爲，有些東西須要和你們分享探討，先書單。

書單

1.《深刻解析SQL Server 2008 系列》 這個就是mssql 2005 的技術內幕系列。2012版的也出了有興趣能夠看看，技術內幕系列是我接觸最先的書，裏面內容涵蓋量很大，可是都是點到爲止。因此不少都是能夠細細品味，回頭再看的。

2.《Troubleshooting SQL Server A Guide for the Accidental DBA》 這本書是我接觸最先的關於性能調優的書。連接已經給出能夠去下載，不過須要註冊SQLServerCenter ，這個網站是SQL Server 方面比較出名的網站。不少國外大牛。

3.《聯機文檔》也就是sql server 裝機後自帶的幫助文檔，內容全面的嚇人，幾乎包含了技術內幕系列的全部內容。

4. 《The.Gurus.Guide.To.SQL.Server.Architecture.And.Internals》這本書是將sql server 2000的內核，從軟件開發的角度來看SQL Server 2000，很深刻做者也十分的出名，惋惜死的太早。對sql server框架理解主要來源於這本書，惋惜沒有中文版。

5.《SQL Server 2008 內核剖析和故障排除》接觸的第二本關於性能調優的書，真本書比較絕的地方時，先將原理再講調優。全書分爲2部分第一部分就是原理，第二部分是性能調優。也 是不錯的一本，書中對擴展事件的功能作了比較詳細的解釋。我在其餘書上是沒看到過的。

該書的2012英文原版已經出了。

6.《Microsoft SQL Server企業級平臺管理實踐》是一本少見的國產好書，書的編寫很符合中國人心理，直指問題自己，很適合當工具書。其中有關於性能跟蹤調整，從捕獲處處理講的很實際。

7.《SQLSERVER求生祕籍》和 《The.Gurus.Guide.To.SQL.Server.Architecture.And.Internals》是同一個做者，這本書主要是針 對SQL Server 2005和上一本同樣對個別點講的很深刻，缺點講到的東西太少。

8.《SQL Server 2008查詢性能調優》這本書比較實用的一本書，講了各個瓶頸的發現，性能基線的簡歷，從查詢，存儲過程角度出發，分析性能，講解可能出現性能問題的點。

9.《Pro SQL Server 2008 Service Broker》 講解關於Service Broker，異步消息處理程序，不少比較大的公司會使用，我知道的是新蛋是使用這個的，全書圍繞一個大例子比較清晰，容易接受。

10.《Pro SQL Server 2008 Policy-Based Management》關於策略管理方面的知識，我的以爲比較雞肋。

 

安全性

樓主是小公司的DBA因此關於安全性使用的比較少，就管理一些權限和密碼

可用性

到SQL Server 2012實現了多種可用性方案，1.日誌傳送，2.數據庫複製，3.數據庫鏡像，4.alwaysonline。

1.日誌傳送，樓主以爲是數據庫鏡像的雛形。沒有數據庫鏡像那樣試試的傳送和redo日誌

2.數據庫複製，數據庫複製有比較多的分類：快照，事務，合併。事務複製是被應用最廣的，從sql server 2000到sql server 2005事務複製被改進了很對具體能夠看聯機文檔。

3.數據庫鏡像，我對於不須要讀寫分離的數據庫中，數據庫鏡像是被應用最廣的可用性方案，數據庫鏡像和其餘的比最突出的優勢是切換方便。

高性能

DBA的大頭應該是性能調優。性能的調優大頭是索引，最求更高的性能索引是必不可少的。一個性能主要體現的執行時間上，執行時間= 運行時間+等待時間。這個公式我以爲很經典。當你沒有頭緒的時候能幫你梳理清楚應該怎麼排查問題。作性能調優必定要對性能的指標十分熟悉。

 

性能基線

當你剛剛入職一家公司，對公司數據庫如今的負載一無所知，那麼一開始要作的事情就是建立一個數據庫性能基線。有人會問基線能用來幹什麼，不少人感受沒用，我剛入職時我也以爲沒用。可是性能基線是一個性能調優，監控的開始。

 

通常比較正規的公司，一個業務上線前會經過壓力測試預計這個服務器的性能邊境在哪裏，到達性能邊境以後各個性能指標的表現是如何的。若是若是性能基線接近了性能邊界，到了這個時候，那麼就要考慮換服務器或者加服務器了。這個是性能基線的一個用處。

 

拿到一個服務器我先會作一下性能基線，性能基線也就是服務器在正常運轉的時候數據庫的性能指標的表現。我會抓取24小時的性能指標做爲性能基線（能夠看我相關的文章：SQL Server 性能基線和監控，SQL Server 性能調優(性能基線)）。

 

如下是我使用的抓取的指標

cpu：

　　　　\Processor(_Total)\% Processor Time
　　　　\Processor(_Total)\% Privileged Time

　　　　\SQLServer:SQL Statistics\Batch Requests/sec
　　　　\SQLServer:SQL Statistics\SQL Compilations/sec
　　　　\SQLServer:SQL Statistics\SQL Re-Compilations/sec
　　　　\System\Processor Queue Length
　　　　\System\Context Switches/sec

　　Memory:

　　　　\Memory\Available Bytes
　　　　\Memory\Pages/sec
　　　　\Memory\Page Faults/sec
　　　　\Memory\Pages Input/sec
　　　　\Memory\Pages Output/sec
　　　　\Process(sqlservr)\Private Bytes
　　　　\SQLServer:Buffer Manager\Buffer cache hit ratio
　　　　\SQLServer:Buffer Manager\Page life expectancy
　　　　\SQLServer:Buffer Manager\Lazy writes/sec
　　　　\SQLServer:Memory Manager\Memory Grants Pending
　　　　\SQLServer:Memory Manager\Target Server Memory (KB)
　　　　\SQLServer:Memory Manager\Total Server Memory (KB)

　　Disk:

　　　　\PhysicalDisk(_Total)\% Disk Time
　　　　\PhysicalDisk(_Total)\Current Disk Queue Length
　　　　\PhysicalDisk(_Total)\Avg. Disk Queue Length
　　　　\PhysicalDisk(_Total)\Disk Transfers/sec
　　　　\PhysicalDisk(_Total)\Disk Bytes/sec
　　　　\PhysicalDisk(_Total)\Avg. Disk sec/Read
　　　　\PhysicalDisk(_Total)\Avg. Disk sec/Write

　　SQL Server:

　　　　\SQLServer:Access Methods\FreeSpace Scans/sec
　　　　\SQLServer:Access Methods\Full Scans/sec
　　　　\SQLServer:Access Methods\Table Lock Escalations/sec
　　　　\SQLServer:Access Methods\Worktables Created/sec
　　　　\SQLServer:General Statistics\Processes blocked
　　　　\SQLServer:General Statistics\User Connections
　　　　\SQLServer:Latches\Total Latch Wait Time (ms)
　　　　\SQLServer:Locks(_Total)\Lock Timeouts (timeout > 0)/sec
　　　　\SQLServer:Locks(_Total)\Lock Wait Time (ms)
　　　　\SQLServer:Locks(_Total)\Number of Deadlocks/sec
　　　　\SQLServer:SQL Statistics\Batch Requests/sec
　　　　\SQLServer:SQL Statistics\SQL Re-Compilations/sec

指標表明啥意思我就不解釋了，你能夠開perfmon，挨個看說明。

假設你如今已經有了性能指標了，那麼你就能夠根據性能基線簡歷告警了，之前的文章（SQL Server 性能基線和監控）中我已經提供了使用powershell如何監控性能。

 

性能運行性能問題分析：

基線建好了監控也建好了，出現告警了。按講關於調優的書上就會開始分開，分爲CPU瓶頸，IO瓶頸，仍是內存瓶頸講。關於這些瓶頸的確認我這裏就不必說了，在之前的文章SQL Server 性能調優（io），SQL Server 性能調優（cpu），SQL Server 性能調優（內存）都有講到。如何確認各個瓶頸。

 

其實這些辨認瓶頸的方法都是不夠全面的，瓶頸確認須要經驗，由於每每出現性能問題了，不是一個指標，而是一批指標都有問題，好比當你索引沒建好，致使了全表掃描，io變大，cpu飆高，內存出現分頁，因此有時候十分難判斷。

 

若是已經肯定是那部分照成的性能問題如IO，CPU，內存。歸根結底就只有2中方法，1.調整。2.硬件升級。

 

若是問題出現了，要急着解決問題1.使用top 10 io，top 10 cpu，來查看須要優化的語句根據執行計劃進行調優。還有就是經過profiler，前提是當前服務器還能容許你使用profiler。2008以後出現 了擴展事件，可能能夠經過這個來處理，可是關於擴展事件作跟蹤我尚未涉及，相關資料也不是不少。

 

那麼如何肯定使用內存比較多的語句呢，內存有點特別，sql server把數據放在buffer pool裏面，你們都能用，內存壓力分爲內部和外部，內部是sql server 自身引發的內存壓力，外部是其餘進程照成的內存壓力（相關的只是能夠查看sql server 2005 troubleshooting 白皮書）。

出現內存瓶頸也就是buffer pool滿了，要清除原先的buffer pool數據才能把新讀入的數據存放在裏面，那麼就簡單了，那個語句讀取的最多那麼哪一個語句使用內存最多（詳細內容能夠查看《Microsoft SQL Server企業級平臺管理實踐》）。

 

那麼假設已經定位到了一個出問題的SQL語句，那麼接下來就是要優化它，裏面使用到的最關鍵的就是執行計劃。如何根據執 行計劃優化SQL語句不一樣的人想法都不太同樣。優化方法和各有特點。因此再也不升入以避免以偏概全。可是運行時間主要仍是這樣幾點：執行計劃，統計信息，索 引。

性能等待問題分析：

等待時間：鎖等待，閂鎖等待。

關於資源等待，這裏有三篇文章，《SQL Server 性能調優 Wait Event》，《SQL Server 性能調優 Wait Event （二）》，《SQL Server 2008 性能調優 session級別 wait event》做者是同一我的。經過WaitEvent的角度來調整。因此在此以前須要先了解關於sys.dm_os_wait_stats 中相關指標主要指的是什麼意思，關於這個SQL Server出了一個《SQL Server 2005 Waits and Queues》很詳細的介紹了各個指標的意思。《SQL Server 2008查詢性能調優》中有個很好的關於收集堵塞狀況的SQL語句。

 

當收集到堵塞若是是出如今鎖級別上的，那麼沒有其餘辦法，用索引或者在select 語句上面加nolock， 或者開帶快照的隔離級別，可是我的比較不同意快照隔離級別，有朋友已經測試過，一開快照隔離級別，tempdb的負載增長十分明顯，一個問題解決致使了另 外一個更棘手的問題。如果select語句，儘可能使用覆蓋索引，來減小由於引用多個索引致使和update死鎖的狀況。固然這個也看具體的系統運行環境而 定。

 

若是是出如今閂上，通常比較大的指標是PAGEIOLATCH_x系列的，WRITELOG，PAGELATCH_x,tempdb上的PAGELATCH_x。

 

PAGEIOLATCH_x是在等待磁盤io時產生的，會產生磁盤io的緣由也就是內存中沒有數據，就是內存不夠纔會出現這種情況，那麼就加內存吧。或者優化一下業務規則。

 

WRITELOG 是寫入日誌的時候出現了等待，日誌是順序寫的，本質就是事務多寫入時磁盤速度不夠快出現了等待，若是有問題建議1.把日誌和數據文件分開，放到2個獨立的盤或者raid，2.換成速度更快的盤。

 

PAGELATCH_x是操做buffer pool數據頁產生的閂。若是等待過大，很簡單就是調用這個頁的session過多，那麼就減小對頁面的訪問。1.經過索引優化語句，儘可能減小sql讀取的頁面數量。2.想辦法把頁面的數據分散多個頁面。3.考慮讀寫分離。

 

tempdb上的PAGELATCH_x主要發生在GAM，SGAM，PFS幾個頁面，由於order by，group by，臨時表，表變量，lazy操做符。都會使用到tempdb，會開闢一個空間。若是併發量大。那麼tempdb上的PAGELATCH_x的等待將會 很大。1.減小執行計劃中sort操做符，減小lazy操做符。2.把tempdb的數據文件擴展，上限是cpu個數（有個條件是tempdb容量要平 衡）。