今天在給資料表字段做長度變更時,遇到一點問題.由於是生產環境,在為該表做變更操作時刻意挑的操作低峰時段.正常10m左右可以完成的操作執行了20分鐘左右還是正在執行中.查詢會話狀態,發現該會話狀態是suspended,等待型別是PAGEIOLATCH_EX.

檢視網上對該等待型別的解釋，原來是資料頁沒有快取在記憶體裡。SQL Server在緩衝池裡找到一個頁面的空間，在上面申請一個EX的latch，防止資料從磁盤裡讀出來之前，有別人也來讀取或修改這個頁面。對整個page加鎖相當於是在記憶體中預定了一片空間用於存放需要從磁碟中physical read來的page。
（詳細連結：

http://www.cnblogs.com/xwdreamer/archive/2012/08/30/2663232.html）
為防止造成大量堵塞，影響業務，KILL掉該程序，發現此時該會話狀態變成下圖狀態

使用語句kill 483with statusonly 查看回滾進度，返回資訊如下：

10分鐘後查看回滾進度，仍舊顯示此狀態。網上搜索發現幾乎所有網友的解決辦法都是重啟服務。但是重啟服務會導致部分操作無效，可能會造成資料丟失，不到萬不得已，最好不要重啟服務。
此時檢視資料庫堵塞資訊，發現已造成大量堵塞，堵塞語句主要是讀取系統表獲取表結構的SQL語句。

想到對於該等待型別的解釋，我kill掉了正在進行的SELECT操作會話，降低IO壓力，等了幾分鐘，該會話回滾完成。
作為一個小白，我想起曾經有人和我說：不經歷過驚魂時刻都不是好DBA，每一次驚魂，對於DBA都是 get stronger的過程。現在我感觸頗深。遇到問題不要慌，不要急，要抓住細節，從源頭分析，這樣才能命中問題，