台灣最大程式設計社群網站
線上人數
721
 
會員總數:244989
討論主題:188956
歡迎您免費加入會員
討論區列表 >> Blog精華文章 >> DBCC OPENTRAN case
[]  
[我要回覆]
回應主題 加入我的關注話題 檢舉此篇討論 將提問者加入個人黑名單
DBCC OPENTRAN case
價值 : 0 QP  點閱數:774 回應數:0

樓主

花旗蔘 版主
高級專家
10938 129
4319 516
發送站內信

------CASE:最近發現tempdb 的ldf檔變得滿大的,已經壓迫到磁碟的空間,去check ldf檔的使用率
dbcc sqlperf(logspace)

發現size為8gb多 使用率為 98%以上,而tempdb 的復原模式為simple(不可更改為 full或bulk-logged)
即然為simple recovery model,那會自動清除inactive的交易紀錄(在checkpoint時),
所以如今ldf 為8gb多且使用率98%以上,應是在tempdb中有active的交易造成,
等交易確認(commit/rollback)後,ldf檔內的空間會釋放出來,使用率會下降,
到時再shrinkfile tempdb 的ldf,把部份空間還給os,
但觀察了兩天,發現tempdb 的LDF長得9GB多且使用率還是98%以上,
此時判斷應是有long pending的交易造成,

此時可用DBCC OPENTRAN來找出指定資料庫中 最舊的使用中交易,

DBCC OPENTRAN('tempdb')
/*資料庫'tempdb' 的交易資訊。

 最早的現用交易:
    SPID (伺服器處理序識別碼) : 58
    UID (使用者識別碼) : -1
    名稱         : sort_init
    LSN           : (14867:1336:36)
    啟動時間   : 02  1 2012  6:27:13:147PM
DBCC 的執行已經完成。如果DBCC 印出錯誤訊息,請聯絡您的系統管理員。
*/
有交易於2/1 啟動,今天已是2/16了, 判斷應是這個long pending的交易造成的 SPID:58,

sp_who2
dbcc inputbuffer(58)
檢查一下 這SESSION 送出的最後一個陳述式。


該SESSION 的WATITME 很大,WAITTYPE 為NETWORK IO

最後請AP人員CHECK,判斷應該是 該程式(ETL)的SESSION 掛了,
取得允許後,KILL掉該SESSION,ldf檔內的空間就釋放出來,
再shrinkfile
use tempdb
sp_helpdb tempdb

dbcc shrinkfile('templog',1000)
-------------------------------------


本篇文章發表於2012-02-17 15:10
== 簽名檔 ==
Oracle/EBS/MS SQL DBA
--My BLOG
http://itgroup.blueshop.com.tw/benchenBEN/blog
別忘捐VP感謝幫助你的人 新手會員瞧一瞧
目前尚無任何回覆
   

回覆
如要回應,請先登入.