程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 數據庫知識 >> 其他數據庫知識 >> 更多數據庫知識 >> sqlserver中幾種典型的等待,sqlserver幾種典型

sqlserver中幾種典型的等待,sqlserver幾種典型

編輯:更多數據庫知識

sqlserver中幾種典型的等待,sqlserver幾種典型


為了准備今年的雙11很久沒有更新blog,在最近的幾次sqlserver問題的排查中,總結了sqlserver幾種典型的等待類型,類似於oracle中的等待事件,如果看到這樣的等待類型時候能夠迅速定位問題的根源,下面通過一則案例來把這些典型的等待處理方法整理出來:

第一種等待.memory等待

早上接到一用戶反饋其RDS實例非常的慢,通過觀察sqlserver活動會話監視器(active monitor)的waiting tasks(類似於mysql的thread running)可以看到有10多w的等待任務,可以明確數據庫現在已經出現了較大的瓶頸,緊接著通過resource waits看到數據庫中有大量的memory內存等待:

看到是memory 資源等待後,為了立刻恢復用戶應用,想到立刻去調大內存,發現該實例已經是24G了,看來一下os的空余內存,還有較多的內存剩余,所以將內存調大到36G,發現resource waits還是在memory上等待,同時這個時候的cpu使用率飙升,達到了90%左右(之前在10%左右的等待).這樣解決不了根本問題,於是通過recent expensive queries,發現以下sql的邏輯讀很高,執行非常頻繁:

SELECT * FROM RefundOrder_Message messages0_ WHERE messages0_.Order_Id=@p0;

也可以通過如下方式獲得造成內存等待的sql:
SELECT st.text FROM sys.dm_exec_query_memory_grants req CROSS APPLY sys.dm_exec_sql_text(req.sql_handle) as ST where req.grant_time is NULL or req.granted_memory_kb is NULL

The columns grant_time and granted_memory_kb will be NULL for those queries which are waiting to get their requested memory

sp_helpindex RefundOrder_Message
發現該表只有一個主鍵索引:

創建一下索引:
create index ind_RefundOrder_Message_order_id on RefundOrder_Message(Order_Id);

第二種等待:latch等待


在索引加上去後,memory的等待立刻消失,但是resource waits的等待變為了 lock:

通過以下內部視圖可以發現如下調用出現了等待:
SELECT ss.host_name, req.blocking_session_id,req.wait_type ,req.wait_time ,req.wait_resource ,req.transaction_id ,st.text FROM sys.dm_exec_requests req CROSS APPLY sys.dm_exec_sql_text(req.sql_handle) as ST
cross apply sys.dm_exec_sessions ss where req.status =N'suspended' and ss.session_id=req.session_id;

得到阻塞其他會話的sql:
(@p0 int,@p1 nvarchar(4000),@p2 bit)
SELECT TOP (@p0) this.* FROM ViewSalesOrder this_ WHERE this_.MemberCode = @p1 and this_.IsObsolete = @p2 ORDER BY this_.OdCode desc;

視圖ViewSalesOrder是一張非常核心的視圖,裡面關聯了訂單,訂單消息,訂單發貨等多個業務邏輯;查詢條件中代入了membercode為店鋪的名稱,可能操作某個店鋪的訂單;
通過ViewSalesOrder視圖中的定義,membercode,IsObsolete ,OdCode 為salesOrder表的三個字段,查看salesOrder上並沒有相應的索引,於是加上如下索引:
create index ind_salesOrder_member on salesOrder(membercode,IsObsolete,code);
在添加完索引後,數據庫的waiting tasks 下降,batch requests提升:

第三種等待:lock

第三種等待是常見的等待,常見的情況在刪除,更新的時候由於條件中沒有合適的索引導致鎖定的記錄范圍太大,導致阻塞其他的會話請求:

用戶在在進行壓測的時候發現一條更新語句執行的非常慢,導致整個系統都卡住:

update DD_ShenHe   set ZF = 0   where zf is null;

查看dd_shenhe表上面的索引:

可以看到表中並沒有zf字段的索引,而該表總共有400w的數據,zf 為null的有8000條,所以在zf字段添加索引是合適的:

Create index ind_dd_shenhe_zf on dd_shenhe(zf);

添加完索引後,系統恢復正常。

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved