事故背景:一大早還在路上,群里陸續(xù)有人反饋系統(tǒng)一直報錯 “ Unknown error 258 ”,后來查詢?nèi)罩景l(fā)現(xiàn)錯誤日志
![](http://img.jbzj.com/file_images/article/201912/201912383349494.png?20191138344)
第一反應(yīng)是不是數(shù)據(jù)庫連接不夠用了?導(dǎo)致超時?但是通過sql查詢當(dāng)時連接也只有40個左右,于是繼續(xù)排查問題,發(fā)現(xiàn)dbserver機器這段時間磁盤io操作特別的高,很不正常,詳見下圖
![](http://img.jbzj.com/file_images/article/201912/201912383429269.jpg?201911383438)
發(fā)現(xiàn)磁盤io問題,繼續(xù)查看sqlserver日志,發(fā)現(xiàn)原因: “Autogrow of file ‘xxxx_log' in database ‘xxxx' was cancelled by user or timed out after 3398 milliseconds. Use ALTER DATABASE to set a smaller FILEGROWTH value for this file or to explicitly set a new file size.”
![](http://img.jbzj.com/file_images/article/201912/201912383523465.jpg?201911383533)
發(fā)現(xiàn)這種問題因為log日志文件太大了一直沒有壓縮過,并且創(chuàng)建數(shù)據(jù)庫的時候默認(rèn)選擇了10%的增量來擴(kuò)大log增量文件,這樣日志文件的10%會越來越大從而產(chǎn)生超時高io操作
解決方案:
1、定期清理log文件,防止log文件越來越大
USE [master]
GO
ALTER DATABASE 數(shù)據(jù)庫名 SET RECOVERY SIMPLE WITH NO_WAIT
GO
ALTER DATABASE 數(shù)據(jù)庫名 SET RECOVERY SIMPLE
GO
USE 數(shù)據(jù)庫名
GO
DBCC SHRINKFILE (N'數(shù)據(jù)庫名_Log' , 11, TRUNCATEONLY)
GO
USE [master]
GO
ALTER DATABASE 數(shù)據(jù)庫名 SET RECOVERY FULL WITH NO_WAIT
GO
ALTER DATABASE 數(shù)據(jù)庫名 SET RECOVERY FULL
GO
2、修改默認(rèn)數(shù)據(jù)庫log增量10% 為 500M(看具體情況,一般夠了)
總結(jié)
以上就是這篇文章的全部內(nèi)容了,希望本文的內(nèi)容對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值,謝謝大家對腳本之家的支持。
您可能感興趣的文章:- SQL Server 2008 清空刪除日志文件(瞬間日志變幾M)
- SQL Server 數(shù)據(jù)庫清除日志的方法
- SQL Server 壓縮日志與減少SQL Server 文件大小的方法
- SqlServer修改數(shù)據(jù)庫文件及日志文件存放位置
- SQL Server 2005刪除日志文件的幾種方法小結(jié)
- SqlServer數(shù)據(jù)庫提示 “tempdb” 的日志已滿 問題解決方案
- SQL Server 2000 清理日志精品圖文教程
- sqlserver 數(shù)據(jù)庫壓縮與數(shù)據(jù)庫日志(ldf)壓縮方法分享
- SQLServer日志清空語句(sql2000,sql2005,sql2008)