从分析SQLSERVER ERRORLOG查找错误折射出的工作效率问题

从分析SQLSERVER ERRORLOG查找错误折射出的工作效率问题

前几天,在备份某一台服务器上的某一个库的时候遇到问题,数据库80G+,在完整备份的时候,SQLSERVER报错

消息 3271,级别 16,状态 1,第 49 行
在文件 "E:\DataBase\xxxxxx\FG_xxxxx_ClassId_05_data.ndf" 上发生不可恢复的 I/O 错误: 2(系统找不到指定的文件。)。
消息 3013,级别 16,状态 1,第 49BACKUP DATABASE 正在异常终止。

 

服务器上挂有20+个数据库,所有数据库都能完整备份,唯独这个库有问题,数据库名称:9115

这里有问题会有两种可能:

1、数据库由于某些原因损坏

2、磁盘有问题导致数据库损坏

 

在某个晚上我对数据库进行了checkdb的修复,修复时间大概3个多小时

何总说可以先重启服务器,因为他曾经试过重启服务器,数据库的损坏问题又正常了

但是我不敢贸然重启服务器,怕重启了起不来

大家可能觉得checkdb了,修复了就可以正常备份,备份完了就完事了,能不能正常备份我还不清楚,因为磁盘空间不太够

但是作为DBA最起码要追查一下原因

 

有三个疑问需要追查:

(1)从什么时候开始这个数据库就已经损坏了???

(2)其他库有没有出现同样的错误(发生不可恢复的 I/O 错误: 2(系统找不到指定的文件)???

(3)这个库是不是从别的服务器那里搬过来的,如果是,是搬过来之前就有损坏,还是搬过来之后才损坏???

 

追查就要依靠SQLSERVER ERRORLOG

说了这麽久,好像跟效率不沾边???


效率问题

首先我们管理着上千个数据库,每天的工作,从上班忙到下班,下班忙到睡觉,系统如此之多

怎麽才能快速查找出这两个疑问的答案呢?

难题:SQLSERVER ERRORLOG日志文件很大,直接用SQLSERVER自带的日志查看器来加载会报“out of memory”或“出现多个错误”或“SSMS直接崩溃”

 

用UE??更不用想了,直接崩溃

 

步骤1:虽然在服务器上直接查看也可以,但是我担心的是

1、会影响服务器性能

2、如果重启SQL或机器,最老的日志就没有了

先压缩这几个errorlog,然后拷贝到本地,其实拷贝到本地作为一个备份的作用,而且想怎麽查就怎麽查

 

步骤2:怎麽才能查看这麽大的日志文件?在本机安装一个SQLSERVER,然后替换

安装路径\Microsoft SQL Server\MSSQL.1\MSSQL\LOG下面的日志文件

替换的时候要注意,不用每个都替换,只需要替换第5和第6个日志文件,因为这两个文件都上GB级别

 

步骤3:替换了之后,打开SSMS,我们需要查找第6个文件里有“系统找不到指定的文件”字眼的

日志记录,确定时间,第6个文件的修改时间是2012-11-3,我们就从2012-1-1开始查找

如果2012-1-1之前还有记录,我们就再修改一下时间,而结束时间我们就选择2015-10-10

保证可以覆盖到整个日志文件

输入下面的SQL语句

EXEC xp_readerrorlog 0,1,'9115','系统找不到指定的文件','2016-01-01','2018-10-10','DESC'

查找到没有记录,用了9分钟时间

步骤4:继续查找第6个日志文件,看一下9115这个库是从什么时候开始存在在这个服务器上的

使用下面的SQL语句

EXEC xp_readerrorlog 6,1,'9115',NULL,'2011-05-09','2018-10-10','DESC'

可以看到在2012-06-11 的时候这个库就已经存在在这台服务器上

 

步骤5:继续查找第5个日志文件

查到了,用了42秒,查到5行记录,最早出现问题是在2013-11-18 00:35:48

A read of the file 'E:\DataBase\xxxx\FG_xxxxx_ClassId_05_data.ndf' at offset 0x00000009668000 succeeded after failing 1 time(s) with error: 2(系统找不到指定的文件。). Additional messages in the SQL Server error log and system event log may provide more detail. This error condition threatens database integrity and must be corrected. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.

 问题一和问题三解开了

(1)从什么时候开始这个数据库就已经损坏了???

最早出现(系统找不到指定的文件)问题是在2013-11-18 00:35:48

(3)这个库是不是从别的服务器那里搬过来的,如果是,是搬过来之前就有损坏,还是搬过来之后才损坏???

是不是搬过来不清楚,不过可以肯定的是,这个库在这台服务器上跑了一段时间才出现这个问题的,可以说明刚开始的时候数据库是没有问题的

 

步骤6继续第二个问题

使用下面SQL语句来查看第5和第6个日志文件,排查其他库有没有出现同样的错误

EXEC xp_readerrorlog 6,1,NULL,'系统找不到指定的文件','2011-12-12','2018-10-10','DESC'

EXEC xp_readerrorlog 5,1,NULL,'系统找不到指定的文件','2011-12-12','2018-10-10','DESC'

 

第6个日志文件没有任何记录

第5个日志文件都是9115这个数据库的,而9457这个数据库应该是还原的时候找不到bak文件

 

步骤7这个时候大家一定会想继续使用SQL语句来继续查找错误

但是,因为第一个日志文件是不能替换的,就算停掉SQL,开启SQL之后又会重新生成,大家可能会替换来替换去,改文件名

虽然改文件名使用SQL语句这些方法也可以,但是这篇文章强调的两个字是“效率

 

观察一下各个日志文件的大小,ERRORLOG.4才21MB

我们完全可以用SQLSERVER自带的日志查看器来查看

为什麽用SQLSERVER自带的日志查看器而不用UE等文本编辑工具,因为SQLSERVER自带的日志查看器的筛选功能比UE好很多

而且筛选出来的结果很直观,很好用,效率也不相差多少

1、改名

2、在消息包含文本框里输入“系统找不到指定的文件”

 

第4个日志文件一条记录都没有

同样,在第3、2、1个日志文件也是一条记录都没有

注意:

只要应用了“筛选器”之后,你在加载下一个ERRORLOG文件的时候,日志查看器就会自动帮你筛选出符合要求的记录

而不会显示全部记录!!

 

在ERRORLOG里面找到39条符合要求的记录,全部都是9115这个库的

第二个问题解开了,只有9115这个库出现 (发生不可恢复的 I/O 错误: 2(系统找不到指定的文件) 的错误

 


总结

每天的工作中,我会把每天做的工作记录下来,也会遇到同样的问题可以快速找到解决办法

在工作量这么多的情况下,如何减轻自己的工作量,不停反思才能提高工作效率~

 

一个小小的总结的,希望大家多多支持o(∩_∩)o 

 

 

参考文章:

听风吹雨

SQL Server 错误日志过滤(ERRORLOG)

 

如有不对的地方,欢迎大家拍砖o(∩_∩)o 

 

2014-5-11补充

昨晚成功完整备份了数据库9115,保证了数据安全,可能还有一些数据页损坏,不过成功备份了数据库就可以进行下一步的工作:检查硬盘

 

 

检查死锁

 


dbcc traceon(1204,1222,-1)
dbcc tracestatus(1204,1222,-1)
1204
返回参与死锁的锁的资源和类型,以及受影响的当前命令。

1222
以不符合任何 XSD 架构的 XML 格式,返回参与死锁的锁的资源和类型,以及受影响的当前命令。--作用域:仅全局

posted @ 2014-05-10 17:34  桦仔  阅读(3074)  评论(3编辑  收藏  举报