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

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

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

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

案例1.

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

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

Select * from master..sysprocesses where blocked > 0

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

dbcc inputbuffer(51);

結果如下：

EventType Parameters EventInfo

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

RPC Event 0 p_Book_content;1

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

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

Sp_lock

結果如下（大部分數(shù)據(jù)略）

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

。。

。。

。。

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

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

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

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

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

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

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

注：原來發(fā)在csdn的，現(xiàn)在荒蕪了，挪到這邊來栽培一下。

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