提供給你,小弟都是用以下的itam來分析的...

資源 效能物件 效能計數器 效能瓶頸條件 建議的效能調整方法
記憶體 Memory Pages/Sec 5 以下 增加記憶體大小
記憶體 Memory Available MBytes 100 MB以下 同上
處理器 Processor % Processor Time 75% 以下 升級處理器速度或增加處理器個數
處理器 System Processor Queue Length 2 以下 同上
硬碟 PhysicalDisk Avg. Disk Queue Length 2 以下 1. 換更快速的磁碟機
2. 資料庫檔案的檔案群組重新規劃分散於不同的磁碟陣列
硬碟 PhysicalDisk Avg. Disk Read Queue Length 2 以下 同上
硬碟 PhysicalDisk Avg. Disk Write Queue Length 2 以下 同上

記憶體 Buffer Manager Buffer Cache Hit Ratio 90 以下 增加記憶體大小
記憶體 Memory Manager Target Server Memory 超過實體記憶體大小 增加記憶體大小
記憶體 Memory Manager Total Server Memory 70~80% 以上 增加記憶體大小
tempdb Access Methods Worktables From Cache Ratio 愈高愈好
tempdb Databases Data File Size 可以得知是否持續增加
交易記錄檔 Databases Log File Size 10~25%
Date File Size 備份或清除交易記錄檔，然後壓縮檔案
交易記錄檔 Databases Percent Log Used 70~80% 以上 備份或清除交易記錄檔

要看效能的話，有很多東西都要看：
記體體使用量、緩衝區使用量、連線數量、快取使用量、鎖定的狀態、CPU 使用量...

除了透過 Performance Monitor 來監控伺服器的效能狀態外
很多時候，效能的瓶頸來自於
1.伺服器的組態設定是恰當？（如 Memory 給定的值與作業系統本身記憶體空間的搭配）
2.tempdb 的空間是否足夠？
3.master db的空間有沒有給大一點（預設是30MB，可以加大一點)
4.每個 database 的 transaction log 空間是否足夠？(比例可設為 5:1 即 100 MB DB 搭配 20 MB Log)
5.有沒有將 Auto Shrink 選項勾起來
6.資料庫備份的模式是否搭配得宜？

除此之外，更多的效能瓶頸來自於
1.SQL Command 下得是否合宜？
2.Table 本身的 Index 是否有妥善的規劃？
3.甚至於您的 Primany Key 的定義是否恰當（數字與文字當 Primary Key的效能差異很大，數據需查）？

要觀測 SQL Command 的執行成本，可以利用 Query Analyzer 來執行 SQL Command 時，
將 Execution Plan 選項打開，可以看出 SQL Command 的執行成本以及所使用的 Index，
來驗證您所建立的 Index 是否恰當

更可以使用 SQL Profiler 來 Monitor SQL Server 的存取狀態
http://ithelp.ithome.com.tw/question/10008073