诊断SQL Server问题常用的日志概述及使用

一、使用Windows事件日志定位系统与基础故障

Windows事件日志是排查SQL Server外部环境和基础服务健康度的第一道关卡。作为Windows系统的一部分，它会记录SQL Server服务的启动、正常关闭以及因异常导致的终止等信息。当遇到连接认证问题或需要界定问题性质时，这些日志提供了重要的线索。

第1步：打开事件查看器

目的：访问系统日志以查看SQL Server相关事件。
操作：
1. 按下 Win + R 键打开“运行”对话框。
2. 输入 eventvwr 并按回车确定。

在不同版本的Windows（如Win7、Server 2008等）中，界面布局可能略有差异，但核心功能一致。

第2步：关注关键日志类别

入口：在事件查看器左侧导航栏展开“Windows日志”。
重点关注：
- 应用程序 (Application)：大多数SQL Server产生的概要信息位于此。如果来源名称显示为 MSSQLSERVER，则为数据库产生的记录。
- 系统 (System)：反映操作系统整体健康情况，包括硬件或软件异常。
- 安全 (Security)：仅在处理连接认证等特定安全问题时需要偶尔查看。

每条记录都包含日期、时间、来源和事件ID，分为信息、警告和错误三类。


若遇到服务器响应缓慢，双击某条记录可查看详细信息。例如，若系统内存不足导致页面文件频繁交换，事件日志中通常会显示相关警告，提示内存资源紧张。此时需结合服务器配置（如32位系统限制）进行优化，例如计划迁移至64位操作系统以充分利用内存。

第3步：导出与跨机器分析日志

操作：右键点击“事件查看器(本地)”树形结构下的对应日志类别，选择“将事件另存为...”。
格式选择：
- *.evt：可使用事件查看器再次打开，方便像在本机一样分析。


- *.txt：文本格式，无时区转换问题，适合通过邮件或网络传输后直接用记事本查看。

注意：保存 *.evt 文件时，时间戳基于当时系统的时区设置。若在时区不同的机器上打开（如从美国白天发生的错误到中国晚上查看），时间显示会发生偏移，可能导致排查困难。因此，跨时区分析时建议优先使用文本格式。

二、深入分析SQL Server ErrorLog文件

在确认Windows基本状况后，应直接检查SQL Server自身的 ErrorLog 文件。它记录了整个开启、运行、终止过程，包括版本信息、启动参数、数据库挂载状态及各类内部错误。

第1步：定位ErrorLog路径

方法A：默认路径
通常在安装目录下的 LOG 子文件夹中。示例路径：
C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\LOG\errorlog
（注：MSSQL.1 中的数字取决于实例名称和安装顺序。）

方法B：通过配置管理器查看
1. 打开SQL Server配置管理器。
2. 选中SQL Server服务，右键选择“属性”。
3. 进入“高级”选项卡，查找“转储目录”或“启动参数”。

在“启动参数”中，找到以 -e 开头的参数，其后跟随的路径即为当前ErrorLog的实际存储位置。

第2步：读取与分析ErrorLog内容

工具：由于日志通常为文本格式且体积不大，可使用记事本、SSMS（SQL Server Management Studio）或其他文本编辑器打开。

关键信息清单
ErrorLog主要记录以下内容，排查时需逐一核对：
1. SQL Server版本及操作系统/处理器基本信息。
2. 启动参数、认证模式及内存分配情况。
3. 各数据库能否正常打开；若失败，记录具体原因。
4. 数据库损坏相关的严重错误。
5. 备份与恢复动作的记录。
6. DBCC CHECKDB 的执行结果。
7. 内存相关的错误或警告。
8. SQL调度异常警告（常伴随服务器挂起/SERVER HANG）。
9. I/O操作长时间延迟警告。
10. 其他高级别错误。
11. 内部访问越界错误（Access Violation）。
12. 服务关闭时间。

分析策略
首先确认ErrorLog是否为空。若有错误或警告，需核对其发生时间是否与用户反馈的问题时间点吻合。若时间对应，则重点分析该时间段内的上下文信息。

第3步：启用详细日志追踪（可选）

为了获取更详细的运行时信息，可以在数据库中执行以下命令开启特定的跟踪标志。这有助于记录用户登录情况及详细的死锁信息。

DBCC TRACEON(1222);
GO
DBCC TRACEON(1204);
GO

说明：
- 开启后，所有成功或失败的登录尝试将被记录。
- 死锁及其参与者的详细信息将被输出到ErrorLog中。

三、ErrorLog的局限性

虽然ErrorLog至关重要，但它并非万能，以下三类问题通常不会直接在日志中体现：

1. 阻塞问题：只要阻塞未严重影响到SQL Server的线程调度，日志中通常无体现。
2. 普通性能问题：若性能瓶颈源于表结构设计或语句逻辑而非内存、I/O或线程调度异常，ErrorLog不会自动记录。
3. Windows层面异常：若操作系统出现非响应或工作不正常，SQL Server往往无法自我判断，需依赖前述的Windows事件日志进行辅助定位。

综上所述，排查SQL Server问题时应采取“先看Windows事件日志排除系统与资源异常，再细读SQL ErrorLog定位引擎内部错误”的策略。

以上就是诊断SQLSERVER问题常用的日志概述及使用的详细内容，更多关于SQL Server数据库排错与维护的资料请关注本站其它相关文章！