自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

SQL Server 2008應(yīng)用 阻塞(Blocking)

開(kāi)發(fā)
在SQL Server 2008中經(jīng)常會(huì)猶豫一些愿意造成人為的產(chǎn)生阻塞(Blocking)。下文會(huì)介紹阻塞的原因并怎樣解決。

        在Sql Server 2008中當(dāng)一個(gè)數(shù)據(jù)庫(kù)會(huì)話中的事務(wù)正鎖定一個(gè)或多個(gè)其他會(huì)話事務(wù)想要讀取或修改的資源時(shí),會(huì)產(chǎn)生阻塞(Blocking)。通常短時(shí)間的阻塞沒(méi)有問(wèn)題,且是較忙的應(yīng)用程序所需要的。然而,設(shè)計(jì)糟糕的應(yīng)用程序會(huì)導(dǎo)致長(zhǎng)時(shí)間的阻塞,這就不必要地鎖定了資源,而且阻塞了其他會(huì)話讀取和更新它們。

發(fā)生長(zhǎng)時(shí)間阻塞的原因如下:

       1、在一個(gè)沒(méi)有索引的表上的過(guò)量的行鎖會(huì)導(dǎo)致SQL Server得到一個(gè)鎖,從而阻塞其他事務(wù)。

       2、應(yīng)用程序打開(kāi)一個(gè)事務(wù),并在事務(wù)保持打開(kāi)的時(shí)候要求用戶進(jìn)行反饋或交互。這通常是讓最終用戶在GUI上輸入數(shù)據(jù)而保持事務(wù)打開(kāi)的時(shí)候發(fā)生。此時(shí),事務(wù)引用的任何資源都會(huì)被占據(jù)。

       3、事務(wù)BEGIN后查詢的數(shù)據(jù)可能在事務(wù)事務(wù)開(kāi)始前被調(diào)用

       4、查詢不恰當(dāng)?shù)厥褂面i定提示。例如,應(yīng)用程序僅使用很少的行,但卻使用一個(gè)表鎖提示

       5、應(yīng)用程序使用長(zhǎng)時(shí)間運(yùn)行的事務(wù),在一個(gè)事務(wù)中更新了很多行或很多表(把一個(gè)大量更新的事務(wù)變成多個(gè)更新較少的事務(wù)有助于改善并發(fā)性)

一、找到并解決阻塞進(jìn)程

       下面我們演示使用SQL Server動(dòng)態(tài)管理視圖sys.dm_os_waiting_tasks找出阻塞進(jìn)程,該視圖用于代替早期SQL Server版本中的系統(tǒng)存儲(chǔ)過(guò)程sp_who

找出阻塞的進(jìn)程后,我們使用sys.dm_exec_sql_text動(dòng)態(tài)管理函數(shù)和sys.dm_exec_Connections(DMV)找出正在執(zhí)行的查詢的SQL文本,然后強(qiáng)制結(jié)束進(jìn)程。

強(qiáng)制結(jié)束進(jìn)程,我們使用kill命令。kill的用法,請(qǐng)參看MSDN:http://msdn.microsoft.com/zh-cn/library/ms173730.aspx

該命令有三個(gè)參數(shù):

       session ID 要終止的進(jìn)程的會(huì)話 ID。session ID 是在建立連接時(shí)為每個(gè)用戶連接分配的***整數(shù) (int)。在連接期間,會(huì)話 ID 值與該連接捆綁在一起。連接結(jié)束時(shí),則釋放該整數(shù)值,并且可以將它重新分配給新的連接。使用 KILL session ID 可終止與指定的會(huì)話 ID 關(guān)聯(lián)的常規(guī)非分布式事務(wù)和分布式事務(wù)。

       UOW 標(biāo)識(shí)分布式事務(wù)的工作單元 (UOW) ID。UOW 是可從 sys.dm_tran_locks 動(dòng)態(tài)管理視圖的 request_owner_guid 列中獲取的 GUID。也可從錯(cuò)誤日志中或通過(guò) MS DTC 監(jiān)視器獲取 UOW。有關(guān)監(jiān)視分布式事務(wù)的詳細(xì)信息,請(qǐng)參閱 MS DTC 文檔。使用 KILL UOW 可終止孤立的分布式事務(wù)。這些事務(wù)不與任何真實(shí)的會(huì)話 ID 相關(guān)聯(lián),與虛擬的會(huì)話 ID = '-2' 相關(guān)聯(lián)??墒箻?biāo)識(shí)孤立事務(wù)變得更為簡(jiǎn)單,其方法是查詢 sys.dm_tran_locks、sys.dm_exec_sessions 或 sys.dm_exec_requests 動(dòng)態(tài)管理視圖中的會(huì)話 ID 列。

       WITH STATUSONLY 生成由于更早的 KILL 語(yǔ)句而正在回滾的指定 session ID 或 UOW 的進(jìn)度報(bào)告。KILL WITH STATUSONLY 不終止或回滾 session ID 或 UOW,該命令只顯示當(dāng)前的回滾進(jìn)度。

在***個(gè)查詢窗口:

  1. BEGIN TRANUPDATE Production.ProductInventory  
  2. SET Quantity = 400  
  3. WHERE ProductID = 1 ANDLocationID = 1 

第二個(gè)窗口:

  1. UPDATE Production.ProductInventory  
  2. SET Quantity = 406  
  3. WHERE ProductID = 1 ANDLocationID = 1 

第三個(gè)窗口:

  1. SELECT blocking_session_id, wait_duration_ms, session_id  
  2. FROM sys.dm_os_waiting_tasks  
  3. WHERE blocking_session_id IS NOT NULL/*blocking_session_id    wait_duration_ms    session_id  
  4. 52    23876    54*/ 

       可以看出是SessionID為52的會(huì)話阻塞了SessionID為54的會(huì)話。

       那么,52正在干啥壞事呢?在第三個(gè)窗口中執(zhí)行:

  1. SELECT t.text  
  2. FROM sys.dm_exec_connections cCROSS APPLY sys.dm_exec_sql_text (c.most_recent_sql_handle) t  
  3. WHERE c.session_id = 54  
  4. /*text  
  5. (@1 int,@2 tinyint,@3 tinyint)UPDATE [Production].[ProductInventory] set [Quantity] = @1  WHERE [ProductID]=@2 AND [LocationID]=@3*/                

       我們強(qiáng)制終止會(huì)話。在第三個(gè)窗口中執(zhí)行:

  1. kill 52 

       注意:窗口一的語(yǔ)句和窗口二的語(yǔ)句均終止。

       提示:第三個(gè)語(yǔ)句中,使用sys.dm_exec_connections(DMV)返回了Session ID為53的most_recent_sql_handle列。這是SQL文本在內(nèi)存中的指針。作為sys.dm_exec_sql_text動(dòng)態(tài)管理函數(shù)的輸入?yún)?shù)使用。從sys.dm_exec_sql_text返回了text列,該列顯示了阻塞進(jìn)程的SQL文本。如果阻塞成串,必須通過(guò)blocking_session_id和session_ID列仔細(xì)查看每一個(gè)阻塞進(jìn)程,直到發(fā)現(xiàn)原始的阻塞進(jìn)程。


二、配置語(yǔ)句等待鎖釋放的時(shí)長(zhǎng)

       如果有一個(gè)事務(wù)或語(yǔ)句被阻塞,意味著它在等待資源上的鎖被釋放。我們可以事先通過(guò)set lock_Timeout來(lái)設(shè)定需要等待的時(shí)間。

       語(yǔ)法如下:SET LOCK_TIMEOUT time_period

       參數(shù)以毫秒為單位。超過(guò)時(shí)會(huì)返回鎖定錯(cuò)誤。示例:

       在***個(gè)窗口中執(zhí)行:

  1. USE AdventureWorks  
  2. BEGIN TRAN  
  3. UPDATE Production.ProductInventory  
  4. SET Quantity = 400  
  5. WHERE ProductID = 1 ANDLocationID = 1 


 

       在第二個(gè)窗口中執(zhí)行:
 

  1. USE AdventureWorks  
  2. SET LOCK_TIMEOUT 1000  
  3. UPDATE Production.ProductInventory  
  4. SET Quantity = 406  
  5. WHERE ProductID = 1 ANDLocationID = 1  
  6. /*1秒后的執(zhí)行結(jié)果Msg 1222, Level 16, State 51, Line 3Lock request time out period exceeded.The statement has been terminated.*/ 


 

       解析:在這個(gè)示例中,我們?cè)O(shè)置了鎖超時(shí)時(shí)間為1000毫秒,即1秒。這個(gè)設(shè)置不會(huì)影響資源被進(jìn)程占有的時(shí)間,只會(huì)影響等待另一個(gè)進(jìn)程釋放資源訪問(wèn)的時(shí)間。
 

       在 Sql server中如果產(chǎn)生了長(zhǎng)時(shí)間的阻塞,是對(duì)資源的浪費(fèi),我們應(yīng)該盡快的解決。

       【編輯推薦】

  1. 微軟SQL Server 2008令商業(yè)智能平民化
  2. SQL Server 2008幾項(xiàng)新特性概述
  3. 如何解決SQL Server占用內(nèi)存的問(wèn)題
  4. SQL Server如何訪問(wèn)sybase數(shù)據(jù)庫(kù)的表
  5. 如何實(shí)現(xiàn)SQL Server 2005快速web分頁(yè)
責(zé)任編輯:佚名 來(lái)源: 博客園
相關(guān)推薦

2011-03-11 13:26:32

SQL ServerBlocking阻塞

2011-02-28 13:19:50

SQL Server SQL死鎖

2011-03-11 10:35:31

SQL鎖定SQL Server

2011-02-21 13:06:42

Microsoft S

2010-07-20 11:35:41

避免SQL Serve

2009-04-16 17:55:15

擴(kuò)展熱插拔SQL Server

2011-08-19 13:46:22

SQL Server 組裝有序集合

2009-04-16 15:30:15

SQL Server 可用性應(yīng)用場(chǎng)景

2010-06-03 11:39:33

2010-07-20 11:18:12

SQL server阻

2011-08-19 14:03:36

SQL Server 檢索集合

2011-08-19 14:38:22

SQL Server 2008遞歸查詢

2009-02-24 13:15:22

FILESTREAM新特性SQL Server

2010-03-23 09:52:23

SQL Server

2009-04-16 17:44:31

2009-04-16 18:15:19

動(dòng)作審核審核活動(dòng)SQL Server

2009-04-16 17:34:19

2011-03-29 12:42:25

SQL Server 高效性

2011-04-07 09:56:53

SQL Server 內(nèi)存

2010-07-20 11:26:08

SQL Server阻
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)