監(jiān)控前言

上一節(jié)我們提到了MSSQL的基于SQL Event的監(jiān)控，但是有些時(shí)候我們需要更加詳細(xì)、適用于調(diào)優(yōu)排錯(cuò)的監(jiān)控。SQL Server內(nèi)部運(yùn)行的可見性是的查詢調(diào)整、優(yōu)化和綜合排查成為可能！這一節(jié)主要和大家說說SQL Server跟蹤（SQL Server Profile）的一些監(jiān)控方式和途徑。

　　使用場景

記得某次給一家公司調(diào)優(yōu)的時(shí)候，負(fù)責(zé)人發(fā)給我一堆業(yè)務(wù)的T-SQL腳本，我面對海量腳本還是從容，雖然不了解內(nèi)部復(fù)雜的業(yè)務(wù)，但是我們得專注問題的關(guān)鍵 慢，我們根據(jù)查詢的慢把他們篩選出來，一一調(diào)式優(yōu)化，不就迅速解決問題嗎？三天后，負(fù)責(zé)人含淚握著我的手，哥們辛苦了，查詢響應(yīng)得到了質(zhì)的改善。

　　跟蹤提供者

SQL Server 為我們兩者提供跟蹤的方式：一種是一個(gè)物理文件（可保存在本機(jī)或者UNC網(wǎng)絡(luò)路徑），一種是行集。對于后者大家應(yīng)該比較熟悉

　　這個(gè)工具在 SSMS 的 工具 SQL Profile

　　詳細(xì)的我暫時(shí)不介紹，先說說兩者的區(qū)別和類同點(diǎn) DIFFAndSame(行集,文件提供者)。

• 兩者都是用類似Buffer來保存當(dāng)前的事件數(shù)據(jù)，很明顯是為了減少IO的壓力，這樣可以不阻塞和盡量不遺漏 事件數(shù)據(jù)，當(dāng)Buffer 到達(dá)一定量時(shí)候可能才會(huì)Flush到磁盤或者發(fā)送到網(wǎng)絡(luò)的終端（客戶端）顯示監(jiān)控行集。
• 物理文件保存監(jiān)控結(jié)果的方式的重要保證是不能遺漏任何事件，一旦IO降速的時(shí)候，可能會(huì)影響到整個(gè)T-SQL的執(zhí)行情況。

   SELECT * FROM sys.dm_os_wait_stats WHERE wait_type IN ('SQLTRACE_LOCK','IO_COMPLETION');        
  
          
  
          
          
        
          
  it知識(shí)庫：SQL Server監(jiān)控系列之調(diào)優(yōu)排錯(cuò)，轉(zhuǎn)載需保留來源！
          
  鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時(shí)間聯(lián)系我們修改或刪除，多謝。