今天在給數據表字段做長度變更時,遇到一點問題.由於是生產環境,在爲該表做變更操作時刻意挑的操作低峯時段.正常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的過程。現在我感觸頗深。遇到問題不要慌，不要急，要抓住細節，從源頭分析，這樣才能命中問題，