用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语句

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

使用下面的SQL语句

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

 

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

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

第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 

从分析SQLSERVER ERRORLOG查找错误折射出的工作效率问题,布布扣,bubuko.com