从分析SQLSERVER ERRORLOG查找错误折射出的工作效率问题
前几天，在备份某一台服务器上的某一个库的时候遇到问题，数据库80G+，在完整备份的时候，SQLSERVER报错
消息 3271，级别 16，状态 1，第 49 行 在文件 "E:DataBasexxxxxxFG_xxxxx_ClassId_05_data.ndf" 上发生不可恢复的 I/O 错误: 2(系统找不到指定的文件。)。 消息 3013，级别 16，状态 1，第 49 行 BACKUP 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 ServerMSSQL.1MSSQLLOG下面的日志文件
替换的时候要注意，不用每个都替换，只需要替换第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:DataBasexxxxFG_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
参考文章：
听风吹雨
如有不对的地方，欢迎大家拍砖o(∩_∩)o
2014-5-11补充
昨晚成功完整备份了数据库9115，保证了数据安全，可能还有一些数据页损坏，不过成功备份了数据库就可以进行下一步的工作：检查硬盘
检查死锁
dbcc traceon(1204,1222,-1)
dbcc tracestatus(1204,1222,-1)
1204
返回参与死锁的锁的资源和类型，以及受影响的当前命令。
1222
以不符合任何 XSD 架构的 XML 格式，返回参与死锁的锁的资源和类型，以及受影响的当前命令。--作用域：仅全局