SqlServer性能监控和优化总结
生活随笔
收集整理的這篇文章主要介紹了
SqlServer性能监控和优化总结
小編覺得挺不錯(cuò)的,現(xiàn)在分享給大家,幫大家做個(gè)參考.
如何監(jiān)視和查看sql server的性能
http://jingyan.baidu.com/article/a378c9609af34eb32828303a.html打開sql server studio management
打開"工具"-"sql server profiler"
點(diǎn)擊連接
點(diǎn)擊運(yùn)行
可以看到捕捉到的一些訪問數(shù)據(jù)庫的事件，其中有讀寫，點(diǎn)用cpu，持續(xù)時(shí)間等信息可以參考
點(diǎn)擊某個(gè)事件，可以查看具體執(zhí)行了什么sql腳本，進(jìn)一步分析相關(guān)邏輯。
========
利用sql server監(jiān)控?cái)?shù)據(jù)庫訪問
http://jingyan.baidu.com/article/f3e34a12a92bc3f5eb6535ba.html本例分享使用sql server中的profiler監(jiān)控?cái)?shù)據(jù)庫的操作情況。
1
打開sql server profiler；
2
新建跟蹤；
3
連接數(shù)據(jù)庫服務(wù)器并運(yùn)行跟蹤程序；
4
只要保持程序是運(yùn)行狀態(tài)，就可以即時(shí)的監(jiān)測(cè)到數(shù)據(jù)庫的操作情況了。如圖所示，是本例示范時(shí)數(shù)據(jù)庫
的訪問狀況。
========
sql server 在占用服務(wù)器內(nèi)存居高不下怎么辦
簡(jiǎn)介：本人在開發(fā)sql server數(shù)據(jù)庫項(xiàng)目的過程中發(fā)現(xiàn)了這么一個(gè)問題，通過360安全衛(wèi)士的浮動(dòng)顯示圖
標(biāo)表示 sql server 2005 居然像oracle一樣占用了80%的系統(tǒng)資源，消耗資源居高不下，怎么回事啊？
問了一起工作的同事，他們給出了下面的幾個(gè)建議：
1、做個(gè)軟件自動(dòng)給sql server 2005數(shù)據(jù)庫強(qiáng)制釋放內(nèi)存；
注：這個(gè)是可以的，但是這樣做很不合理；一方面服務(wù)器上的web系統(tǒng)正在運(yùn)行，如果此時(shí)我們把系統(tǒng)的
內(nèi)存釋放掉了這樣肯定會(huì)引起網(wǎng)頁OA系統(tǒng)的異常。
2、給sql server 2005 做個(gè)任務(wù)來釋放內(nèi)存；這個(gè)好像是可以的！但是這個(gè)也是很麻煩的事情。
很明顯上面的方法都不是最理想的。
下面就是正確處理由于sql server 2005引起的數(shù)據(jù)庫內(nèi)存居高不下的辦法：
首先我們需要登錄 sql server 2005的資源管理器
鼠標(biāo)右擊我們sql server 2005的服務(wù)器，然后選擇“屬性”選項(xiàng)
找到指定數(shù)據(jù)庫服務(wù)器的屬性中的“內(nèi)存”屬性，并點(diǎn)擊
接下來就是配置數(shù)據(jù)庫內(nèi)存了，可以參考我本地的配置如下圖：
最后點(diǎn)擊“確定”按鈕就可以了！
========
怎么設(shè)置sql2008數(shù)據(jù)庫最大服務(wù)器內(nèi)存
http://jingyan.baidu.com/article/ceb9fb10b415bb8cac2ba078.html通過設(shè)置SQL Server 2008 R2服務(wù)器中的最大服務(wù)器內(nèi)存，可以解決使用數(shù)據(jù)庫時(shí)占用系統(tǒng)內(nèi)存過高的
問題。那么我們?cè)撛趺床僮髂?
1.選擇“開始 > 所有程序 > Microsoft SQL Server 2008 R2 > SQL Server Management Studio”。系
統(tǒng)顯示“連接到服務(wù)器”界面。
2.輸入各項(xiàng)數(shù)據(jù)，單擊連接
3.系統(tǒng)顯示“對(duì)象資源管理器”界面
4.上圖單擊右鍵，在彈出的快捷菜單中選擇“屬性”。
5.在左側(cè)導(dǎo)航欄中選擇“內(nèi)存”，將右側(cè)“最大服務(wù)器內(nèi)存”的值設(shè)置為物理內(nèi)存的60%，本例以8G內(nèi)存
為例
6.最后單擊確定，設(shè)置完成
怎么設(shè)置sql2008數(shù)據(jù)庫最大服務(wù)器內(nèi)存
END
========
對(duì)SQLSERVER進(jìn)行性能監(jiān)控
http://www.cnblogs.com/lyhabc/archive/2013/07/13/3187581.html在上一篇文章《SQLSERVER性能監(jiān)控級(jí)別步驟》里說到性能監(jiān)控的步驟中有一步涉及到建立性能基線，但
是沒有說到有哪些計(jì)數(shù)器
可以用來進(jìn)行監(jiān)控的，這篇文章結(jié)合《企業(yè)級(jí)平臺(tái)管理實(shí)踐》的書本說一下監(jiān)控SQLSERVER有哪些計(jì)數(shù)器
可以用到的
3、建立性能基線
?當(dāng)確定了性能監(jiān)控中所涉及的資源、負(fù)載和目標(biāo)后，開始進(jìn)行監(jiān)控，并建立性能基線與當(dāng)前服務(wù)器性能
進(jìn)行比較。
性能基線是一個(gè)保證系統(tǒng)正常操作性能范圍值，達(dá)到或超過這個(gè)范圍，系統(tǒng)性能可能會(huì)顯著下降。
應(yīng)該對(duì)接近或超過性能基線的數(shù)字做進(jìn)一步調(diào)查找出原因監(jiān)控的周期是一段時(shí)間，而不是一兩天。
其中應(yīng)該包括數(shù)據(jù)庫活動(dòng)的峰值時(shí)間和非峰值時(shí)間，數(shù)據(jù)查詢和批處理命令的響應(yīng)時(shí)間、數(shù)據(jù)庫備份和
還原所需時(shí)間
建立服務(wù)器性能基線后，將基線統(tǒng)計(jì)與當(dāng)前服務(wù)器性能進(jìn)行比較。對(duì)高于或遠(yuǎn)低于基線的數(shù)字需要做進(jìn)
一步調(diào)查。
他們可能表明有需要調(diào)整或重新配置的區(qū)域。例如，執(zhí)行一組查詢的時(shí)間增加，檢查這些查詢以確定能
否重新編寫他們，
或者是否添加統(tǒng)計(jì)信息或索引
介紹：
性能監(jiān)視器 Performance Monitor
性能監(jiān)視器是Windows的一個(gè)工具，在系統(tǒng)管理工具組里。默認(rèn)里面就有很多Windows層面的性能計(jì)數(shù)器
，可以監(jiān)視系統(tǒng)的運(yùn)行。
直接運(yùn)行"perfmon"，也可以打開他。這里以 WindowsXP/2003/2008的性能監(jiān)視器為例。
Windows2008R2和Windows7的性能監(jiān)視器界面有了比較大的變化，功能也有擴(kuò)展，更加好用。同時(shí)也完全
向前兼容。
后面談到的功能都有包括
SQLSERVER自己開發(fā)了一些擴(kuò)展的性能計(jì)數(shù)器。在安裝SQLSERVER的時(shí)候，會(huì)注冊(cè)到Windows里。
這樣， Windows的性能監(jiān)視器就能看到一些以“SQL”打頭的計(jì)數(shù)器了。SQLSERVER在運(yùn)行時(shí)，會(huì)統(tǒng)計(jì)這
些計(jì)數(shù)器的值。
在性能監(jiān)視器里能夠看到：
默認(rèn)性能監(jiān)視器是用來實(shí)時(shí)檢測(cè)系統(tǒng)的，在窗口里，用不同顏色的線條表示不同的計(jì)數(shù)器值。
當(dāng)窗口畫滿以后，會(huì)從頭覆蓋前面的內(nèi)容。所以默認(rèn)只能看到最近一小段時(shí)間的值。
但是在現(xiàn)實(shí)的問題分析中，實(shí)時(shí)監(jiān)測(cè)還是比較少的。更常見的場(chǎng)景是需要在問題發(fā)生之前，就要開啟性
能計(jì)數(shù)器的收集，
收集一段時(shí)間之后，或者問題重現(xiàn)之后，再離線地分析問題的現(xiàn)象和原因。
那么日志怎樣收集呢？
通常可以使用下面這些步驟：
（1）在性能監(jiān)視器左邊的窗口，展開性能 日志和警告子樹，點(diǎn)擊“計(jì)數(shù)器日志” 在右邊的窗口里，右
鍵點(diǎn)擊，
選擇“新 日志設(shè)置”，他會(huì)彈出一個(gè)對(duì)話框，讓你為新的日志記錄配置命名。這里我們?nèi)∶麨門est，日
志默認(rèn)保存路徑是
%systemdrive%\PerfLogs\Admin\Test
（2）在接著彈出的對(duì)話框里，就可以配置DBA要搜集的信息要求了。首先要選擇搜集哪些計(jì)數(shù)器，以及
他們的取樣時(shí)間間隔sample data every，
默認(rèn)是15秒取一次，這個(gè)間隔能夠滿足大部分需求。
有說法講在搜集和磁盤相關(guān)的性能日志時(shí)，間隔要設(shè)置短一點(diǎn)，最好是3到5秒。如果設(shè)置30秒以上，可
能信息就不完整了。
所以15秒是大部分情況下比較好的選擇
（3）選擇添加對(duì)象，就可以選擇要收集的性能監(jiān)視器對(duì)象。對(duì)于非在線分析，問題可能還不清楚，很難
確定哪些性能計(jì)數(shù)器有用，哪些沒有用。
所以在這里，一定要多選一些。一般的SQL問題，可以選擇下面這些對(duì)象
在memory,process,physicaldisk,processor,system對(duì)象下的所有計(jì)數(shù)器，以及他們的所有instance
所有以SQLSERVER：開頭的性能監(jiān)視對(duì)象
如果要監(jiān)視CPU類問題，最好還包含thread下面的所有計(jì)數(shù)器，以及他所有的instance
有些DBA會(huì)擔(dān)心，抓這麼多計(jì)數(shù)器會(huì)不會(huì)影響性能。
應(yīng)該說根據(jù)經(jīng)驗(yàn)，性能監(jiān)視器對(duì)系統(tǒng)整體性能的影響幾乎感覺不到。所以可以比較放心大膽地多收一些
計(jì)數(shù)器。
基本工作原理是在.NET編譯出的IL代碼里放入鉤子用來記錄時(shí)間，然后通過直觀的界面顯示出哪部分代
碼耗能最大。
只是間隔可能還是選15秒比較安全
（4）設(shè)置文件的位置和最大大小 ，另一個(gè)重要配置，是日志文件存放在哪里，保存格式，以及最大大
小。
日志文件的后綴是blg的二進(jìn)制文件，需要使用性能監(jiān)視器才能打開這個(gè)文件
如果性能日志文件大小超過1GB，可能有些機(jī)器打開會(huì)很慢。所以一定要注意其最大值可以設(shè)為200MB。
如果一個(gè)200MB的文件寫滿，性能監(jiān)視器會(huì)自動(dòng)創(chuàng)建一個(gè)新的。文件格式可以選二進(jìn)制文件
日志搜集當(dāng)然可以手動(dòng)開始和終止。但是如果問題會(huì)發(fā)生在半夜，最好能讓系統(tǒng)自動(dòng)開啟，自動(dòng)關(guān)閉。
性能監(jiān)視器也可以幫DBA做到這一點(diǎn)
當(dāng)?shù)玫揭粋€(gè)性能日志后，可以在性能監(jiān)視器里選擇 查看 日志 數(shù)據(jù)
在數(shù)據(jù)源里添加日志文件
然后點(diǎn)擊數(shù)據(jù)選項(xiàng)卡，就能看到在原來那臺(tái)服務(wù)器上收集的性能計(jì)數(shù)器了
這時(shí)候再點(diǎn)擊“源”選項(xiàng)卡，能看見性能日志文件所包含的那段時(shí)間。拉動(dòng)滾動(dòng)條，可以把時(shí)間段縮短
到DBA最關(guān)心的那段時(shí)間
對(duì)收集到的日志，DBA可以進(jìn)行分析
------------------------------華麗的分割線---------------------------
一些性能監(jiān)視器計(jì)數(shù)器
相關(guān)計(jì)數(shù)器
性能對(duì)象 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 計(jì)數(shù)器
SQLSERVER:BUFFER MANAGER: ? ?buffer cache hit ratio,lazy writes/sec ,procedure cache?
pages,total pages
SQLSERVER：Cache Manager: ? ?cache hit ratio,cache object counts,cache pages ,cache use?
counts/sec
SQLSERVER:MEMORY MANAGER: ? ?sql cache memory(kb)
SQLSERVER:SQL STATISTICS: ? ?auto-param attmpts/sec,batch request/sec,failed auto-
params/sec,safe autoparam/sec, sql compilations/sec,
sql re-compilations/sec,unsafe auto-params/sec
----------------------------華麗的分割線--------------------------
與內(nèi)存有關(guān)的計(jì)數(shù)器
Windows與SQLSERVER系統(tǒng)使用內(nèi)存情況和合理配置SQLSERVER內(nèi)存?
性能監(jiān)視器 ?perfmon --添加-》可用計(jì)數(shù)器-》Memory-》添加available MBytes和pages/sec
數(shù)據(jù)收集器集-》用戶定義-》新建-》數(shù)據(jù)收集器集-》名稱：SQLSERVER內(nèi)存使用-》手動(dòng)創(chuàng)建-》性能計(jì)
數(shù)器-》 添加下面的性能計(jì)數(shù)器-》
時(shí)間間隔15秒-》保存路徑：C:\Users\Administrator\Desktop\SQLSERVER內(nèi)存使用-》 保存并關(guān)閉-》
選中剛才創(chuàng)建的數(shù)據(jù)收集器-》啟動(dòng)-》變成
datacollector01 ? -》在用戶定義下面 SQLSERVER內(nèi)存使用 右鍵-》停止或者在空白的地方-》右鍵-》
停止
可以右鍵-》在用戶定義下面 SQLSERVER內(nèi)存使用-》屬性-》更改數(shù)據(jù)收集器保存路徑
?計(jì)數(shù)器
committed bytes:整個(gè)Windows系統(tǒng)，包括Windows自身以及所有用戶進(jìn)程使用的內(nèi)存總數(shù)
commit limit:整個(gè)Windows系統(tǒng)能夠申請(qǐng)的最大內(nèi)存數(shù)，其值等于物理內(nèi)存加上文件緩存大小
available MBytes（重要）:現(xiàn)在系統(tǒng)空閑的物理內(nèi)存數(shù)。這個(gè)指標(biāo)能夠直接反映出Windows層面上有沒
有內(nèi)存壓力跑在Windows2000上會(huì)把空閑內(nèi)存用完知道剩下4MB~10MB。跑在Windows2003或以上就會(huì)留給
Windows多一點(diǎn)的物理內(nèi)存
page file :%usage ?page file:% peak usage ：反應(yīng)緩存文件使用量的多少，使用越多緩存，性能越
差
pages /sec:每秒鐘需要從磁盤上讀取或?qū)懭氲捻撁鏀?shù)目
soft page fault一般不會(huì)帶來性能影響，因此一般不太關(guān)心
一個(gè)良好的系統(tǒng)，他要處理的數(shù)據(jù)應(yīng)該比較長(zhǎng)期地保存在物理內(nèi)存里。如果頻繁換頁/換入換出勢(shì)必影響
性能，pages/sec不能長(zhǎng)時(shí)間保持在一個(gè)比較高的值
對(duì)于一臺(tái)SQL服務(wù)器，如果available MBytes長(zhǎng)期小于10MB，說明物理內(nèi)存不太夠pages/sec 物理內(nèi)存不
足也會(huì)做成頻繁換頁/換入換出 pages/sec不能長(zhǎng)時(shí)間保持在一個(gè)比較高的值
Windows系統(tǒng)自身內(nèi)存使用情況
一個(gè)32位Windows系統(tǒng)，正常內(nèi)存使用大概幾百M(fèi)B --64位Windows系統(tǒng)大概1GB~2GB
--如果發(fā)生內(nèi)存泄漏（一般由硬件驅(qū)動(dòng)造成），Windows會(huì)用到幾個(gè)GB甚至十幾GB，反過來擠壓應(yīng)用的內(nèi)
存
memory :cache bytes --系統(tǒng)的working set，也就是系統(tǒng)使用的物理內(nèi)存數(shù)目，包括高速緩存，頁交換
區(qū)，可調(diào)頁的ntoskrnl.exe 和驅(qū)動(dòng)程序代碼，
以及系統(tǒng)映射視圖
cache bytes計(jì)數(shù)器是下面幾個(gè)計(jì)數(shù)器的和：
system cache resident bytes,system driver resident bytes ,system code resident bytes ,pool?
paged resident bytes
system cache resident bytes:系統(tǒng)高速緩存消耗的物理內(nèi)存。高速緩存的主要功能是提高文件讀寫的
速度
pool paged resident bytes：頁交互區(qū)消耗的物理內(nèi)存
system driver resident bytes：可調(diào)頁的設(shè)備驅(qū)動(dòng)程序代碼消耗的物理內(nèi)存
system code resident bytes：ntoskrnl.exe中可調(diào)頁代碼消耗的內(nèi)存
system pool 內(nèi)存池 ?如果兩個(gè)重要的內(nèi)存池內(nèi)存出現(xiàn)泄漏，或者空間用盡，Windows會(huì)出現(xiàn)奇怪不正常
的行為， 進(jìn)而影響SQL穩(wěn)定運(yùn)行。
所以需要檢查這兩個(gè)內(nèi)存池
pool nonpaged bytes 非換頁內(nèi)存池
pool paged resident bytes 換頁內(nèi)存池
單個(gè)process使用情況
常見場(chǎng)景：available MBytes看出服務(wù)器的內(nèi)存基本用盡，但是從cache bytes看Windows自己沒有使用
多少。
現(xiàn)在要開始分析應(yīng)用程序的內(nèi)存使用了
在選擇對(duì)象的實(shí)例里面要每個(gè)進(jìn)程都要添加進(jìn)計(jì)數(shù)器里面，不要選擇_Total SQL的進(jìn)程是sqlservr
%processor time:是目標(biāo)進(jìn)程消耗的CPU資源數(shù)，包括用戶態(tài)和核心態(tài)的時(shí)間
page faults/sec:是目標(biāo)進(jìn)程上發(fā)生的page faults的數(shù)目
handle count：目標(biāo)進(jìn)程handle(指向object指針)數(shù)目句柄數(shù)。如果進(jìn)程內(nèi)部有對(duì)象老是創(chuàng)建，不及時(shí)
回收，就會(huì)發(fā)生handle leak
thread count:目標(biāo)進(jìn)程的線程數(shù)目。如果進(jìn)程老是創(chuàng)建新線程，不釋放老線程，就會(huì)發(fā)生thread leak
pool paged bytes:是目標(biāo)進(jìn)程所使用的paged pool大小
pool nonpaged bytes:是目標(biāo)進(jìn)程所使用的non-paged pool大小
working set:某個(gè)進(jìn)程的地址空間，存放在物理內(nèi)存的那一部分
virtual bytes:某個(gè)進(jìn)程所申請(qǐng)的虛擬地址空間大小，包括reserved memory 和committed memory
private bytes:某個(gè)進(jìn)程提交了的地址空間commited memory中，非共享部分
假設(shè)有processA 和processB,他們的虛擬地址空間都分成兩部分，核心態(tài)和用戶態(tài) --核心態(tài)是由
Windows控制，所有進(jìn)程共享。
processA --committed memory :1,2,3,4,7 --reserved memory:8 --shared memory:通過特殊API申請(qǐng)
的內(nèi)存，processA和processB都能夠訪問
物理內(nèi)存physical memory：1，3，4，d，7，9，b，c 緩存文件page file：2，y
系統(tǒng)核心態(tài)內(nèi)存 system working set=x
檢查計(jì)數(shù)器主要找到以下：
使用內(nèi)存最多的進(jìn)程
內(nèi)存使用量在不斷增長(zhǎng)的進(jìn)程
出現(xiàn)問題的那個(gè)時(shí)間段，內(nèi)存使用數(shù)量發(fā)生過突變（增或降）的進(jìn)程
這些可以通過working set ?private bytes得到初步答案
?-----------------------------華麗的分割線--------------------
上面這些都是《SQLSERVER企業(yè)級(jí)平臺(tái)管理實(shí)踐》讀書筆記整理出來的一些常用SQLSERVER性能計(jì)數(shù)器，
大家做性能基線的時(shí)候都可以用來做參考
========
SqlServer性能檢測(cè)和優(yōu)化工具使用詳細(xì)
http://blog.csdn.net/dcx903170332/article/details/45917387工具概要 ? ?
? ? 如果你的數(shù)據(jù)庫應(yīng)用系統(tǒng)中，存在有大量表，視圖，索引，觸發(fā)器，函數(shù)，存儲(chǔ)過程，sql語句等等
，又性能低下，而苦逼的你又要對(duì)其優(yōu)化，那么你該怎么辦？哥教你，首先你要知道問題出在哪里？如
果想知道問題出在哪里，并且找到他，咱們可以借助本文中要講述的性能檢測(cè)工具--sql server?
profiler（處在sql安裝文件--性能工具--sql server profiler）
? ? 如果知道啦問題出現(xiàn)在哪里，如果你又是絕世高手，當(dāng)然可以直中要害，寫段代碼給處理解決掉，
但是如果你不行，你做不到，那么也無所謂，可以借助哥的力量給你解決問題。哥給你的武功的秘訣心
法是---數(shù)據(jù)庫引擎優(yōu)化顧問（處在sql安裝文件--性能工具--數(shù)據(jù)庫引擎優(yōu)化顧問）
sql server profiler功能?
? ? 此工具比柯南還柯南，因?yàn)樗軝z測(cè)到數(shù)據(jù)庫中的一舉一動(dòng)，即便你不動(dòng)他，他也在監(jiān)視你，他很
賤的。他不但監(jiān)視，還監(jiān)視的很詳細(xì)，有多詳細(xì)一會(huì)再說，還把監(jiān)視的內(nèi)容記錄到數(shù)據(jù)庫或者是文件中
，給你媳婦告狀說你把數(shù)據(jù)庫哪里的性能搞的多么不好，不過他也會(huì)把好的給你記錄下來，好與不好這
當(dāng)然需要你來分析，其實(shí)他也是個(gè)很2的柯南。
數(shù)據(jù)庫引擎優(yōu)化顧問功能?
? ? 此武功，乃上乘武功。像張無忌的乾坤大挪移，先是接受sql server profiler檢測(cè)出來的sql，視
圖，存儲(chǔ)過程，數(shù)據(jù)結(jié)構(gòu)等等，然后他再自己分析，然后再在懷中轉(zhuǎn)兩圈，感覺自己轉(zhuǎn)的差不多啦，就
給拋出來個(gè)威力更炫，更好的索引，統(tǒng)計(jì)，分區(qū)等等建議信息。讓你承受不住，happly致死。。下面聽
哥給你先講講咱們的很2柯南。
sql server profiler的使用
打開系統(tǒng)主菜單--sqlserver幾---性能工具--->>sql server profiler;笨樣兒，找到?jīng)]？哥等你會(huì)兒，
給你上張打開他后的圖，讓你看看。。
然后文件--新建跟蹤--顯示跟蹤屬性窗口
然后選中頁簽“事件選擇”，并點(diǎn)擊”列篩選器“，操作如下圖：
首先那個(gè)select%是個(gè)篩選監(jiān)測(cè)的TextData。那個(gè)%是個(gè)通配符，他的意思就是篩選select開口的語句。
當(dāng)然這你自己可以隨便定義，如update%，delete%....。
把那個(gè)排除不包含值的行也給帶上，然后確定，運(yùn)行。然后在數(shù)據(jù)庫中運(yùn)行一句select。你會(huì)發(fā)現(xiàn)他檢
測(cè)到啦。
每列以此向右，從EventClass開始，我給你講講都是什么。
事件分類，申請(qǐng)了語句，應(yīng)用程序名稱，操作系統(tǒng)用戶，數(shù)據(jù)庫用戶，cpu占用率，讀數(shù)據(jù)庫次數(shù)，寫數(shù)
據(jù)庫次說，執(zhí)行腳本用時(shí)，應(yīng)用程序進(jìn)程號(hào)，開始時(shí)間，結(jié)束時(shí)間等。
事件選擇，你就把鼠標(biāo)放上去，他下面有中文的注釋。自己好好看看，然后根據(jù)你自己的需要把事件勾
選上來。
然后文件-->>另存為，可以把這些監(jiān)測(cè)到的數(shù)據(jù)保存為文件，或數(shù)據(jù)表。
分析：
1.查找持續(xù)時(shí)間最長(zhǎng)的查詢
一般情況下，最長(zhǎng)查詢時(shí)間的查詢語句就是最影響性能的原因存在。它不僅占用數(shù)據(jù)庫引擎大量的時(shí)間
，還浪費(fèi)系統(tǒng)資源，還影響數(shù)據(jù)庫應(yīng)用系統(tǒng)的交互速度。再對(duì)數(shù)據(jù)用應(yīng)用系統(tǒng)進(jìn)行優(yōu)化時(shí)，先找出他，
對(duì)其優(yōu)化，在創(chuàng)建跟蹤時(shí)，勾上TSQL-SQL:BatchCompleted.跟Stored Procedures-RPC:completed。這樣
就能找出來這個(gè)最長(zhǎng)時(shí)間查詢?nèi)缓髮?duì)其進(jìn)行分析優(yōu)化。
select TextData,Duration,CPU from <跟蹤的表>
where EventClass=12 -- 等于12表示BatchCompleted事件
and CPU<(0.4*Duration) ?--如果cpu的占用時(shí)間，小于執(zhí)行sql語句時(shí)間的40%，說明該語句等待時(shí)間過
長(zhǎng)
2.最占用系統(tǒng)資源的查詢
就是占用cpu時(shí)間，跟讀寫IO的次數(shù)。建議事件包含Connect、Disconnect、ExistingConnection、
SQL:BatchCompleted、RPC:completed，列包含writes，reads，cpu。
3.檢測(cè)死鎖
在訪問量，并發(fā)量都很大的數(shù)據(jù)庫中，如果設(shè)計(jì)稍不合理，就有可能造成死鎖，給系統(tǒng)性能帶來影響。
事件包含：RPC:Starting、SQL:BatchStarting、Lock：DeadLock（死鎖事件）、Lock：
DeadLockChaining（死鎖的事件序列）。
使用數(shù)據(jù)庫引擎優(yōu)化顧問分析解決數(shù)據(jù)庫性能
打開系統(tǒng)主菜單--sqlserver幾---性能工具--->>數(shù)據(jù)庫引擎優(yōu)化顧問，界面如下
打開之后，你在上一個(gè)工具中保存的的文件，你就在這里的工作負(fù)荷中選文件，表就選表。選后別急。
把要分析的數(shù)據(jù)庫跟數(shù)據(jù)庫的表選上，也就是下面的用于工作負(fù)荷分析的數(shù)據(jù)庫選擇，跟下面的要優(yōu)化
的數(shù)據(jù)庫和表，慢慢扣，把他選對(duì)。
然后選則你想要的優(yōu)化選項(xiàng)
根據(jù)需要，選上，高級(jí)選項(xiàng)里面通常可以默認(rèn)。確定。。
然后點(diǎn)左上角有一個(gè)開始分析。如果報(bào)下面的錯(cuò)誤，不要急，按照他的操作一步一步來就行。
點(diǎn)擊tab標(biāo)簽"優(yōu)化選項(xiàng)",如圖：
然后點(diǎn)擊“高級(jí)選項(xiàng)”：、
點(diǎn)擊確定----開始分析-----一會(huì)就分析完成了
?它會(huì)給個(gè)建議列表，然后你根據(jù)上面的操作，把它給出的操作在數(shù)據(jù)庫中操作下就OK了，就不用那么的
費(fèi)盡心機(jī)的調(diào)試SQL了，當(dāng)然寫出高效率的SQL還是比較好的。
========
sql server性能分析--查看表數(shù)據(jù)頁數(shù)
返回表名、索引名和行數(shù)
SELECT object_name(i.object_id) as objectName, i.[name] as indexName, sum(p.rows) as rowCnt
FROM sys.indexes i
INNER JOIN sys.partitions p
ON i.object_id = p.object_id
AND i.index_id = p.index_id
WHERE i.object_id = object_id('dbo.Meeting')
AND i.index_id <= 1
GROUP BY i.object_id, i.index_id, i.[name]
返回表的總頁數(shù)、使用頁數(shù)、數(shù)據(jù)頁數(shù)
SELECT object_name(i.object_id) as objectName, i.[name] as indexName,
sum(a.total_pages) as totalPages, sum(a.used_pages) as usedPages, sum(a.data_pages) as?
dataPages,
(sum(a.total_pages) * 8) / 1024 as totalSpaceMB, (sum(a.used_pages) * 8) / 1024 as?
usedSpaceMB,
(sum(a.data_pages) * 8) / 1024 as dataSpaceMB
FROM sys.indexes i
INNER JOIN sys.partitions p
ON i.object_id = p.object_id
AND i.index_id = p.index_id
INNER JOIN sys.allocation_units a
ON p.partition_id = a.container_id
WHERE i.object_id = object_id('dbo.Meeting')
AND i.index_id <= 1
GROUP BY i.object_id, i.index_id, i.[name]
按頁類型分類統(tǒng)計(jì)
SELECT case when grouping(i.object_id) = 1 then '--- TOTAL ---' else object_name
(i.object_id) end as objectName,
case when grouping(i.[name]) = 1 then '--- TOTAL ---' else i.[name] end as indexName,
case when grouping(a.type_desc) = 1 then '--- TOTAL ---' else a.type_desc end as pageType,
sum(a.total_pages) as totalPages, sum(a.used_pages) as usedPages, sum(a.data_pages) as?
dataPages,
(sum(a.total_pages) * 8) / 1024 as totalSpaceMB, (sum(a.used_pages) * 8) / 1024 as?
usedSpaceMB, (sum(a.data_pages) * 8) / 1024 as dataSpaceMB
FROM sys.indexes i
INNER JOIN sys.partitions p
ON i.object_id = p.object_id
AND i.index_id = p.index_id
INNER JOIN sys.allocation_units a
ON p.partition_id = a.container_id
WHERE i.object_id = object_id('dbo.Meeting')
AND i.index_id <= 1
GROUP BY i.object_id, i.[name], a.type_desc with rollup
========
SQL Server性能之瓶頸的正確查看步驟
http://database.51cto.com/art/201007/210767.htm我們今天主要向大家講述的是正確查出SQL Server性能之瓶頸的實(shí)際操作流程，以及對(duì)SQL Server數(shù)據(jù)
庫性能監(jiān)控的實(shí)際操作描述。
AD：網(wǎng)+線下沙龍 | 移動(dòng)APP模式創(chuàng)新：給你一個(gè)做APP的理由>>
以下的文章主要向大家介紹的是正確查出SQL Server性能之瓶頸的實(shí)際操作流程，假如你對(duì)DBA很了解的
話，那么你就一定會(huì)了解到SQLServe數(shù)據(jù)庫的性能調(diào)優(yōu)不是一個(gè)精密的科學(xué)。即使是，對(duì)于為最佳的SQL?
Server性能找到最佳的配置也是很困難的。
這是因?yàn)閷?duì)于調(diào)優(yōu)來說很少東西是絕對(duì)的。例如，一個(gè)性能調(diào)優(yōu)可能對(duì)某一方面有
如果你曾經(jīng)做了很長(zhǎng)時(shí)間的DBA，那么你會(huì)了解到SQLServe的性能調(diào)優(yōu)不是一個(gè)精密的科學(xué)。即使是，對(duì)
于為最佳的性能找到最佳的配置也是很困難的。這是因?yàn)閷?duì)于調(diào)優(yōu)來說很少東西是絕對(duì)的。例如，一個(gè)
性能調(diào)優(yōu)可能對(duì)某一方面有用，可是卻會(huì)影響其他的性能。
我曾經(jīng)做過DBA，在最后7年的日子里，我總結(jié)了一套SQL Server調(diào)優(yōu)的清單。當(dāng)?shù)谝淮芜M(jìn)行SQL Server
性能調(diào)優(yōu)的時(shí)候，可以用它來作為一個(gè)向?qū)АＮ医?jīng)常被邀請(qǐng)去檢查SQL Server并提供一些性能方面的建
議。直到現(xiàn)在，我還沒有真正寫下一個(gè)貫穿整個(gè)性能調(diào)優(yōu)過程的方案。
但是當(dāng)我做了越來越多的性能調(diào)優(yōu)的咨詢工作后，我現(xiàn)在決定花點(diǎn)時(shí)間整理出來。你將會(huì)發(fā)現(xiàn)它是很有
用的，就象我發(fā)現(xiàn)對(duì)我的用處一樣.
SQL Server性能監(jiān)控
這套性能優(yōu)化的清單將至少準(zhǔn)科學(xué)的幫助你找出你的SQL Server任何明顯的性能問題。說是這樣說，SQL?
Server的性能調(diào)優(yōu)仍然是很困難的。我試圖用這套清單去找出“容易”的SQL Server性能問題，困難的
留待稍后。我這樣做是因?yàn)楹苋菀讓⑷菀缀屠щy的的性能調(diào)優(yōu)問題搞混。通過列出一個(gè)“容易”的性能
調(diào)優(yōu)范圍，就很容易的將這些問題解決，一旦解決了這些容易的問題，那么你就能集中去解決更困難的
問題。
使用這個(gè)SQL Server性能調(diào)優(yōu)清單的一個(gè)好處是，它將不僅僅告訴你目前最容易解決的性能問題是什么
，而且還幫助你正確的去解決。在某種程度上，你可以選擇不同的順序進(jìn)行。換句話說，你可以故意做
出特殊的決定而不是按照清單通常的順序進(jìn)行。
某種意義上說你是對(duì)的，不是所有的SQL Server性能調(diào)優(yōu)建議都適合所有的情形。另外，你的決定是基
于你的資源限制，例如沒有足夠的錢去買滿足負(fù)荷的硬件。如果真是那樣的話，你就別無選擇了。還有
，你的決定可能基于一些政治原因，那是你不得不作出的改變。不管怎樣，你需要知道你能做什么，使
用這個(gè)性能調(diào)優(yōu)清單找出你能改變的范圍并做出相應(yīng)的改變提升你的SQL Server的性能。
一般來說，你將在你的每一個(gè)SQL服務(wù)器上執(zhí)行這個(gè)清單。如果遇到清單中的一些問題，這會(huì)花掉你一些
時(shí)間。我建議你從目前性能問題最多的的服務(wù)器開始，然后當(dāng)你有時(shí)間的時(shí)候按照自己的思路去解決其
他服務(wù)器。
一旦你完成了，可仍然有很多事情要去做。記住，這些只是一些容易的。一旦你完成了這些容易的，接
下來你需要花時(shí)間去解決更困難問題。這個(gè)是另一篇文章要解決的問題了。
怎樣進(jìn)行你的SQL Server性能調(diào)優(yōu)呢?
為了使其變得容易，我把它們分成了以下幾個(gè)部分：
使用性能監(jiān)視器找出硬件瓶頸
SQL Server硬件性能監(jiān)控列表
操作系統(tǒng)性能監(jiān)控列表
SQL Server2000配置性能監(jiān)控列表
數(shù)據(jù)庫配置設(shè)置性能監(jiān)控列表
索引性能監(jiān)控列表
應(yīng)用程序和T-SQL性能監(jiān)控列表
SQL Server數(shù)據(jù)庫作業(yè)性能監(jiān)控列表
使用Profiler找出低效的查詢
怎樣最好的實(shí)現(xiàn)SQL Server性能監(jiān)控
管理你的SQLServe性能的最好方法是首先回顧上面每一部分的內(nèi)容，把它們打印出來。然后完成每一部
分的內(nèi)容，寫下你收集到的結(jié)果。你也可以按照你喜歡的順序進(jìn)行。上面的步驟僅僅列出了我執(zhí)行的順
序，因?yàn)槟菢油ǔＤ苓_(dá)到一個(gè)比較好的效果。
一旦你完成其中一部分，你可以按照在清單中發(fā)現(xiàn)的不同的建議進(jìn)行你的性能優(yōu)化工作。然后你將在后
面的部分學(xué)到更多。
以上的相關(guān)內(nèi)容就是對(duì)查出SQL Server性能之瓶頸的介紹，望你能有所收獲。
========
鏈接
http://blog.csdn.net/kufeiyun/article/details/23743647SQL Server查詢性能調(diào)優(yōu)、捕捉和評(píng)估查詢性能
http://www.360doc.com/content/14/0415/14/3112151_369179018.shtml
怎樣查出SQLServer的性能瓶頸
總結(jié)
以上是生活随笔為你收集整理的SqlServer性能监控和优化总结的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 图解Ollydbg简单逆向操作案例
- 下一篇： nosql数据库学习总结