诊断SQLSERVER问题常用的日志
这里主要有两个：
（1）Windows事件日志
（2）SQLSERVER ErrorLog
1、Windows事件日志 Event Log
作为一个Windows开启和管理的服务程序，Windows会在自己的系统日志system log里记录SQLSERVER这个服务的启动、正常关闭、异常关闭等信息。
SQLSERVER也会把自己的一些概要信息同时记录在Windows的应用程序日志里Application Log而Windows日志本身又能够反映操作系统的健康情况，是否有任何软件或硬件的异常。
如果Windows本身不能正常工作，SQLSERVER的运行一定会受到影响。
当遇到一些问题需要微软的售后工程师解决的时候，Windows事件日志是一个很好的界定问题性质的工具。
在Windows里，点击“开始”-》运行 -》输入：eventvwr 点确定 就可以打开事件查看器Event Viewer
在Windows7、Windows2008和Windows2008R2里面，界面会有所不同，但是主要内容还是类似的
Windows主要有三种日志：应用程序，安全，系统 （我的系统是Windows7）
对于SQLSERVER会主要关心应用程序日志和系统日志。当处理一些连接认证问题时，可能会偶尔用上安全日志。
日志里的每一条记录，都属于信息、警告、错误中的一类。
每条记录都会标明日期、时间、来源、事件ID。
如果在应用日志里，从SQLSERVER产生的记录其来源名称都会是MSSQLSERVER
双击某一条记录，Windows会弹出一个对话框，显示记录的具体内容
在这里说一下我遇到的机器内存不足，导致SQLSERVER需要把内存换出去硬盘的情况，导致经常SQLSERVER反应缓慢
事件查看器显示的信息就是上面那个截图，一句话概括就是：系统内存不足
我的机器情况：
8GB内存没有用尽，因为32位操作系统的关系，迟一点打算更换为64位Windows7
所以平时多看一下事件查看器或者遇到问题的时候就先看事件查看器，一定能找到一些问题的蛛丝马迹
另外一个，在事件查看器里，还能把日志另存为*.evt文件或*.txt文件，以供DBA带到其他机器上打开分析。
打开一个*.evt文件的方法是：是右键点击“事件查看器（本地）”树型结构---》打开保存的日志
用这种方法，DBA就能像看本机上的日志记录一样，分析从其他机器保存下来的日志文件了
保存的时候可以保存单个事件或者整个类别的事件
最后，用事件日志查看器打开的日志，其时间会和时区有关系的，
不同时区设置的机器打开一个*.evt文件，其显示的时间会不一样。
例如，如果某个错误信息发生在美国的白天，那么用在中国的机器打开，其时间会显示在晚上
如果你按美国时间找，就会找不到了。但是保存成 *.txt格式 文本文件格式就不会有这种问题
2、SQLSERVER ErrorLog文件
检查完Windows的基本状况后，就可以开始检查SQLSERVER的健康状况。
不管你是遇到什么问题，建议第一个要检查的是SQLSERVER的ErrorLog文件
当SQLSERVER启动的时候，会在某个固定的路径下生成一个“errorlog”的文件
SQLSERVER默认会保留7份errorlog文件，按照时间顺序，依次用文件扩名.1,.2,.3,...,.6表示。
每重启一次服务，文件扩展名都会加一，最早的那份会被删除。
日志文件的默认路径是安装路径下的C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\LOG\LOG子目录。
C:\Program Files是我的机器的安装路径，这个路径是你安装SQLSERVER的时候选择的
当然DBA也能够修改其设置（在配置管理器里，双击sql服务-》高级-》转储目录）
发觉Windows对错误日志或者目录都叫转储的，像某些软件，例如QQ，有道词典好像也是用dmp格式的转储文件
说回正题o(∩_∩)o
如果你要分析的是一台陌生的服务器，可以用很多种方法找到errorlog路径。
一种比较简单的方法是在SQLSERVER 配置管理器里选择SQL服务，在其属性-》高级里找到一个“启动参数”的高级属性
在属性字符串里，会有一个“-e”的参数。他的后面就是跟errorlog文件的位置
或者干脆在上面说的转储目录就可以看到了
errorlog文件以文本方式记录，用任何文件编辑器，包括记事本，SSMS都能打开
一般来讲，errorlog文件的大小不会很大。用这些工具完全能够满足需求
但是，errorlog本身非常重要，他记录了SQL的整个开启、运行、终止过程。
如果SQLSERVER遇到了比较严重的问题，在errorlog里都会有所显示
ErrorLog显示包括以下内容：
（1）SQL的版本，以及Windows和Processor基本信息
（2）SQL的启动参数，以及认证模式，内存分配模式
（3）每个数据库是否能够被正常打开。如果不能，原因是什么
（4）数据库损坏相关的错误
（5）数据库备份与恢复动作记录
（6）DBCC CHECKDB记录
（7）内存相关的错误和警告
（8）SQL调度出现异常时的警告。一般SERVER HANG 服务器死机会伴随着有这些警告
（9）SQL I/O操作遇到长时间延迟的警告
（10）SQL在运行过程中遇到的其他级别比较高的错误
（11）SQL内部的访问越界错误（Access Violation）
（12）SQL服务关闭时间
在检查SQLSERVER相关问题的时候，总是从errorlog着手，先确认errorlog里是干净的。
如果errorlog里有一些错误或警告，就要确认这些错误和警告发生的时间，是不是前端感觉到问题的时间。
如果时间能对得上，那就要着重分析一下
如果开启一些设置，在errorlog里还能看到的有用信息有：
（1）所有用户成功或失败的登入
（2）死锁以及其参与者的信息：需要打开跟踪标志1222 或1204
复制代码 代码如下:
DBCC TRACEON(1222)
DBCC TRACEON(1204)
有时候errorlog也不是万能的哦？他不能反映的问题有：
（1）阻塞问题。只要阻塞还没有严重影响SQLSERVER的线程调度，errorlog里是不会有体现
（2）普通性能问题，超时问题。如果性能问题不是由于内存使用异常、线程调度异常，或者是I/O子系统反应非常缓慢，
而是由于表格或语句设计导致，errorlog里也不会有所反映
（3）Windows层面异常。如果Windows层面出现工作不正常，或者服务器不响应，SQLSERVER很难自我判断的
上面这三个问题，errorlog里一般不会有所体现。这也是我们为什麽要第一步就要检查Event Log的原因
下面给出一个errorlog的内容出来讲解