很多人都遇到過這樣的情況，當網站達到一定的訪問量，數據庫就會成為瓶頸，進而引起阻塞。 有人認為這可能就是硬件的極限了，于是想辦法增加硬件設備。而我本人認為問題的元兇可能是性能不高的sql腳本，引起了阻塞。 如果你和我有相同的看法，那我們就一起想

很多人都遇到過這樣的情況，當網站達到一定的訪問量，數據庫就會成為瓶頸，進而引起阻塞。

有人認為這可能就是硬件的極限了，于是想辦法增加硬件設備。而我本人認為問題的元兇可能是性能不高的sql腳本，引起了阻塞。

如果你和我有相同的看法，那我們就一起想辦法找出問題的源頭。

案例1.

某一天我被告知，我們的書城網站不能訪問了，我馬上查看，發現書城的有兩臺iis服務器均顯示service unavailable，我初步斷定是sqlserver數據庫發生了阻塞，因為同一套程序使兩臺iis服務器同時當機的可能性不大。

要知道是否發生了阻塞，當然要看master庫的sysprocess表,看看是否有什么進程堵住了別的進程,語句如下:

Select * from master..sysprocesses where blocked > 0

很快我發現，有一個blocked = 51 堵住了很多進程(查看blocked列可見)，果然和我的判斷吻合；為了進一步找出發生阻塞的語句，我用到的如下的語句

dbcc inputbuffer(51);

結果如下：

EventType Parameters EventInfo

------------------------------------------------

RPC Event 0 p_Book_content;1

從上面就可以看出是p_Book_content (是個存儲過程)引起的阻塞，但是這個過程里面同時對多個表進行了操作，到底是那個語句出了問題呢？

下面我們再來進一步定位阻塞的位置：

Sp_lock

結果如下（大部分數據略）

Spid dbid objid indid type resource mode status

-------------------------------------------------------------------------------------------------

51 14 206623779 0 TAB X WAIT

52 14 0 0 DB S GRANT

53 14 0 0 DB S GRANT

。。

。。

。。

現在我們來看看spid = 51 這行, mode = X 表示排它鎖, status = WAIT表示正在等待（即被阻塞了），dbid = 14 是數據庫的id，objid = 206623779 是被鎖的對象id,我們可以通過下列函數得到數據庫和表:

Select db_name(@dbid) -----》book_db

select object_name(@objid) -------》 t_book

即book_db庫的t_book表被鎖住了,這時候再回投仔細檢查 p_Book_content 存儲過程，發現只有一個語句對t_book進行了操作:

update t_book set hitcount = hitcount + 1 where bookid = @bookid

這個語句的作用是更新書本的點擊次數，為什么上面這個語句會引起阻塞呢？我認為最可能的情況應該是同時訪問的人過多，同時對表進行過多的update操作引起的，所以最終改用別的方式，不再實時對t_book表進行update操作，而是每次訪問都先insert一條記錄到一個中間表中，然后再用一個作業，每隔10分鐘定時更新書本的點擊次數，如此改進之后，此問題終于圓滿解決了。

相關資料在book online可以找到, 關鍵字: sp_lock , sysprocesses , dbcc inputbuffer , db_name(), object_name()

注：原來發在csdn的，現在荒蕪了，挪到這邊來栽培一下。

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com