| 導購 | 订阅 | 在线投稿
分享
 
 
 

您的SQL Server應用程序查詢正在浪費內存嗎?

2008-12-04 08:26:23  編輯來源:互聯網  简体版  手機版  評論  字體: ||
 
  或許在應用程序代碼中找到的最常見的錯誤就是這樣的查詢請求:它不是使用准備好的查詢或程序,而是使用非參數特設的查詢從數據庫中請求數據。

  不准備你的查詢或者不使用存儲過程會增加不必要的SQL Server計劃緩存。什麽是計劃緩存呢?簡單地說,它是SQL Server共享內存池的一部分,在這裏,解析、編譯和執行優化這些查詢之後,查詢執行計劃仍被保存。無論何時執行一個查詢,內存的這個區域都會被查找,以便確定現有的一個計劃是否可以重新使用來滿足一個查詢請求。重新使用計劃爲數據庫引擎節約了潛在的CPU密集工作,例如,如果唯一的不同點是WHERE從句中正在使用的值,我們不得不一次又一次重新解析,重新編譯,重新優化查詢。這將導致查詢響應時間加快,服務器中的CPU壓力降低。

  下面的java代碼片斷提出一系列非參數特設查詢到AdventureWorks數據庫中,以此來獲得用戶銷售訂單數據。它通過循環,從AdventureWorks SalesOrderHeader表中前20張訂單中獲得信息。

  

您的SQL Server應用程序查詢正在浪費內存嗎?


  

   圖一

  讓我們用SQL Server 2005 DMVs來檢驗計劃緩存中特設查詢的效果。

  

   select qs.usecounts, cacheobjtype, objtype, qt.text

  from sys.dm_exec_cached_plans qs

  cross apply sys.dm_exec_sql_text(qs.plan_handle) as qt

  order by qt.text

  go

  

   注意:下面的查詢輸出結果被修改成只顯示文本字段中的相應資料。

  運行查詢之後,我們可以從下面的圖中看到,每一個查詢執行都在內存中存儲了一個非常具體的計劃,該計劃沒有參數化,也沒有被數據庫引擎重新利用。因爲這些計劃是如此的具體,所以任何這些計劃能夠被重新使用的可能性很小。很容易看到,如果這是一個使用頻率非常高的應用程序,那麽服務器內存會很快地消耗。

您的SQL Server應用程序查詢正在浪費內存嗎?


  現在將調整Java代碼來准備這個查詢語句。在執行之前,我通過命令DBCC FREEPROCCACHE清除該計劃緩存,接著通過一個准備好的語句重新運行java class:

  

您的SQL Server應用程序查詢正在浪費內存嗎?


  

   重新審視這個計劃緩存,我們可以看到,該查詢已經成功編譯並且重新用于所有的執行,因此有效地使用和保存服務器內存和限制CPU使用。

  

您的SQL Server應用程序查詢正在浪費內存嗎?


  

   現在,考慮到由于計劃緩存是內存共享池的一部分,那麽消除多余的計劃可以爲其他緩存騰出更多可用內存,從而使其他的緩存可以使用這個共享池,比如存儲已經從硬盤中讀取到內存中的數據和索引頁的SQL Server數據緩存。

  雖然相對于使用非參數特設的查詢請求來說,准備好的查詢是一種更好的方法,但是比起這兩種方法,我個人更偏向于使用存儲過程。允許直接訪問你的核心數據庫表存在安全風險,通過存儲過程把數據從邏輯中抽取出來可以減少維護,並且當業務需求變化時,它也能夠減少數據模型的變化。無論你選擇哪種數據訪問方法,請記住通過確保你的查詢計劃是可以重複利用的,從而把你的應用程序從潛在的內存和CPU問題中解救出來。
 
或許在應用程序代碼中找到的最常見的錯誤就是這樣的查詢請求:它不是使用准備好的查詢或程序,而是使用非參數特設的查詢從數據庫中請求數據。   不准備你的查詢或者不使用存儲過程會增加不必要的SQL Server計劃緩存。什麽是計劃緩存呢?簡單地說,它是SQL Server共享內存池的一部分,在這裏,解析、編譯和執行優化這些查詢之後,查詢執行計劃仍被保存。無論何時執行一個查詢,內存的這個區域都會被查找,以便確定現有的一個計劃是否可以重新使用來滿足一個查詢請求。重新使用計劃爲數據庫引擎節約了潛在的CPU密集工作,例如,如果唯一的不同點是WHERE從句中正在使用的值,我們不得不一次又一次重新解析,重新編譯,重新優化查詢。這將導致查詢響應時間加快,服務器中的CPU壓力降低。   下面的java代碼片斷提出一系列非參數特設查詢到AdventureWorks數據庫中,以此來獲得用戶銷售訂單數據。它通過循環,從AdventureWorks SalesOrderHeader表中前20張訂單中獲得信息。 [url=/bbs/detail_1884076.html][img]http://image.wangchao.net.cn/it/1323256900315.jpg[/img][/url] 圖一   讓我們用SQL Server 2005 DMVs來檢驗計劃緩存中特設查詢的效果。 select qs.usecounts, cacheobjtype, objtype, qt.text   from sys.dm_exec_cached_plans qs   cross apply sys.dm_exec_sql_text(qs.plan_handle) as qt   order by qt.text   go    注意:下面的查詢輸出結果被修改成只顯示文本字段中的相應資料。   運行查詢之後,我們可以從下面的圖中看到,每一個查詢執行都在內存中存儲了一個非常具體的計劃,該計劃沒有參數化,也沒有被數據庫引擎重新利用。因爲這些計劃是如此的具體,所以任何這些計劃能夠被重新使用的可能性很小。很容易看到,如果這是一個使用頻率非常高的應用程序,那麽服務器內存會很快地消耗。 [url=/bbs/detail_1884076.html][img]http://image.wangchao.net.cn/it/1323256900499.jpg[/img][/url]    現在將調整Java代碼來准備這個查詢語句。在執行之前,我通過命令DBCC FREEPROCCACHE清除該計劃緩存,接著通過一個准備好的語句重新運行java class: [url=/bbs/detail_1884076.html][img]http://image.wangchao.net.cn/it/1323256900746.jpg[/img][/url] 重新審視這個計劃緩存,我們可以看到,該查詢已經成功編譯並且重新用于所有的執行,因此有效地使用和保存服務器內存和限制CPU使用。 [url=/bbs/detail_1884076.html][img]http://image.wangchao.net.cn/it/1323256900915.jpg[/img][/url] 現在,考慮到由于計劃緩存是內存共享池的一部分,那麽消除多余的計劃可以爲其他緩存騰出更多可用內存,從而使其他的緩存可以使用這個共享池,比如存儲已經從硬盤中讀取到內存中的數據和索引頁的SQL Server數據緩存。   雖然相對于使用非參數特設的查詢請求來說,准備好的查詢是一種更好的方法,但是比起這兩種方法,我個人更偏向于使用存儲過程。允許直接訪問你的核心數據庫表存在安全風險,通過存儲過程把數據從邏輯中抽取出來可以減少維護,並且當業務需求變化時,它也能夠減少數據模型的變化。無論你選擇哪種數據訪問方法,請記住通過確保你的查詢計劃是可以重複利用的,從而把你的應用程序從潛在的內存和CPU問題中解救出來。
󰈣󰈤
 
 
 
>>返回首頁<<
 
 
 
 
 熱帖排行
 
王朝網路微信公眾號
微信掃碼關註本站公眾號 wangchaonetcn
 
  免責聲明:本文僅代表作者個人觀點,與王朝網絡無關。王朝網絡登載此文出於傳遞更多信息之目的,並不意味著贊同其觀點或證實其描述,其原創性以及文中陳述文字和內容未經本站證實,對本文以及其中全部或者部分內容、文字的真實性、完整性、及時性本站不作任何保證或承諾,請讀者僅作參考,並請自行核實相關內容。
 
© 2005- 王朝網路 版權所有