2. SQL Server数据库状态监控 - 错误日志

本文涉及的产品
RDS SQL Server Serverless,2-4RCU 50GB 3个月
推荐场景:
云数据库 RDS SQL Server,基础系列 2核4GB
日志服务 SLS,月写入数据量 50GB 1个月
简介: 原文:2. SQL Server数据库状态监控 - 错误日志无论是操作系统 (Unix 或者Windows),还是应用程序 (Web 服务,数据库系统等等) ,通常都有自身的日志机制,以便故障时追溯现场及原因。
原文: 2. SQL Server数据库状态监控 - 错误日志

无论是操作系统 (Unix 或者Windows),还是应用程序 (Web 服务,数据库系统等等) ,通常都有自身的日志机制,以便故障时追溯现场及原因。Windows Event Log和 SQL Server Error Log就是这样的日志, PS: SQL Server 中的错误日志 (Error Log) 类似于 Oracle中的alert 文件。

. 错误日志简介

1. Windows事件日志与SQL Server 错误日志

Windows事件日志中,应用程序里的SQL Server和SQL Server Agent服务,分别对应来源自MSSQLSERVER和SQLSERVERAGENT的日志信息;

SQL Server错误日志中信息,与Windows事件日志里来源自MSSQLSERVER的日志信息基本一致,不同的是,Windows事件日志里信息为应用程序级,较为简洁些,而SQL Server错误日志里通常有具体的数据库错误信息。比如:

Windows事件日志中错误信息:

Login failed for user 'sa'. Reason: Password did not match that for the login provided. [CLIENT: 10.213.20.8]

SQL Server错误日志中错误信息:

Login failed for user 'sa'. Reason: Password did not match that for the login provided. [CLIENT: 10.213.20.8]

Error: 18456, Severity: 14, State: 8.

 

2. 如何理解SQL ServerError message

以上面的Error: 18456, Severity: 14, State: 8.为例:

(1) Error,错误编号,可以在系统表里查到对应的文本信息;

select * From sys.messages where message_id = 18456

(2) Severity,错误级别,表明这个错误的严重性,一共有25个等级,级别越高,就越需要我们去注意处理,20~25级别的错误会直接报错并跳出执行,用SQL语句的TRY…CATCH是捕获不到的;

(3) State,错误状态,比如18456错误,帮助文档记载了如下状态,不同状态代表不同错误原因:

1. Error information is not available. This state usually means you do not have permission to receive the error details. Contact your SQL Server administrator for more information.

2.  User ID is not valid.

5.  User ID is not valid.

6.  An attempt was made to use a Windows login name with SQL Server Authentication.

7.  Login is disabled, and the password is incorrect.

8.  The password is incorrect.

9.  Password is not valid.

11. Login is valid, but server access failed.

12. Login is valid login, but server access failed.

18. Password must be changed.

还有文档未记载的State: 10, State: 16,通常是SQL Server启动帐号权限问题,或者重启SQL Server服务就好了。

 

3. SQL Server 错误日志包含哪些信息

SQL Server错误日志中包含SQL Server开启、运行、终止整个过程的:运行环境信息、重要操作、级别比较高的错误等:

(1)  SQL Server/Windows基本信息,如:版本、进程号、IP/主机名、端口、CPU个数等;

(2) SQL Server启动参数及认证模式、内存分配;

(3) SQL Server实例下每个数据打开状态(包括系统和用户数据库);

(4) 数据库或服务器配置选项变更,KILL操作,开关DBCC跟踪,登录失败等等

(5) 数据库备份/还原的记录;

(6) 内存相关的错误和警告,可能会DUMP很多信息在错误日志里;

(7) SQL Server调度异常警告、IO操作延迟警告、内部访问越界 (也就是下面说到的Error 0);

(8) 数据库损坏的相关错误,以及DBCC CHECKDB的结果;

(9) 实例关闭时间;

另外,可以手动开关一些跟踪标记(trace flags),来自定义错误日志的内容,比如:记录如用户登入登出记录(login auditing),查询的编译执行等信息,比较常用的可能是用于检查死锁时的1204/1222 跟踪标记。

通常错误日志不会记录SQL语句的性能问题,如:阻塞、超时的信息,也不会记录Windows层面的异常(这会在windows事件日志中记载)。

SQL Server Agent错误日志中同样也包括:信息/警告/错误这几类日志,但要简单很多。

 

4. SQL Server 错误日志存放在哪里

假设SQL Server被安装在X:\Program Files\Microsoft SQL Server,则SQL Server 与SQL Server Agent的错误日志文件默认被放在:

X:\Program Files\Microsoft SQL Server\MSSQL.n\MSSQL\LOG\ ERRORLOG ~ ERRORLOG.n

X:\Program Files\Microsoft SQL Server\MSSQL.n\MSSQL\LOG\SQLAGENT.n and SQLAGENT.out.

如果错误日志路径被管理员修改,可以通过以下某种方式找到:

(1) 操作系统的应用程序日志里,SQL Server启动时会留下错误日志文件的路径;

(2) 通过SSMS/管理/错误日志,SQL Server启动时会留下错误日志文件的路径;

(3) SQL Server配置管理器里,点击SQL Server实例/属性/高级/启动参数 (Startup parameters) ;

(4) 通过一个未记载的SQL语句 (在SQL Server 2000中测试无效,2005及以后可以):

SELECT SERVERPROPERTY('ErrorLogFileName')

 

5. SQL Server 错误日志目录下的其他文件

在错误日志目录下除了SQL Server和SQL Server Agent的日志,可能还会有以下文件:

(1) 维护计划产生的report文件 (SQL Server 2000的时候,后来的维护计划log记录在msdb);

(2) 默认跟踪(default trace) 生成的trace文件,PS: 审计(Audit) 产生的trace文件在\MSSQL\DATA下;

(3) 全文索引的错误、日志文件;

(4) SQLDUMP文件,比如:exception.log/SQLDump0001.txt/SQLDump0001.mdmp,大多是发生Error 0时DUMP出来的,同时在错误日志里通常会有类似如下记录:

Error: 0, Severity: 19, State: 0

SqlDumpExceptionHandler: Process 232 generated fatal exception c0000005 EXCEPTION_ACCESS_VIOLATION. SQL Server is terminating this process.

顺便说下ERROR 0 的解释:

You've hit a bug of some kind - an access violation is an unexpected condition. You need to contact Product Support (http://support.microsoft.com/sql) to help figure out what happened and whether there's a fix available.

Is your server up to date with service packs? If not, you might try updating to the latest build. This error is an internal error in sql server. If you are up to date, you should report it to MS.

 

. 错误日志维护

1. 错误日志文件个数

1.1 SQL Server错误日志

SQL Server错误日志文件数量默认为7个:1个正在用的(ERRORLOG)和6个归档的(ERRORLOG.1 – ERRORLOG.6),可以配置以保留更多(最多99个);

(1) 打开到SSMS/管理/SQL Server Logs文件夹/右击/配置;

(2) 通过未记载的扩展存储过程,直接读写注册表也行:

USE [master]
GO
EXEC xp_instance_regwrite N'HKEY_LOCAL_MACHINE', N'Software\Microsoft\MSSQLServer\MSSQLServer', N'NumErrorLogs', REG_DWORD, 50
GO

--Check current errorlog amout
USE [master]
GO
DECLARE @i int
EXEC xp_instance_regread N'HKEY_LOCAL_MACHINE', N'Software\Microsoft\MSSQLServer\MSSQLServer', N'NumErrorLogs', @i OUTPUT
SELECT @i

SQL Server作为一个Windows下的应用程序,很多信息是写在注册表里的,自然也可以手动打开注册表编辑器或写SHELL去修改注册表来作配置。

最后,可以通过 如下SQL语句查看已存在的错误日志编号、起止时间、当前大小。

EXEC master..xp_enumerrorlogs

 

1.2 SQL Server Agent错误日志

SQL Server Agent错误日志文件数量共为10个:1个正在用的(SQLAGENT.OUT),9个归档的(SQLAGENT.1 - SQLAGENT.9),个数不可以修改,但可以配置日志所记载的信息类型:信息、警告、错误。

(1) 打开到SSMS/SQL Server Agent/Error Logs文件夹/右击/配置;

(2) 未记载的扩展存储过程:

USE [msdb]
GO
EXEC msdb.dbo.sp_set_sqlagent_properties @errorlogging_level=7
GO

至于@errorlogging_level各个值的意思,由于没有文档记载,需要自己测试并推算下。

 

2. 错误日志文件归档

2.1 为什么要归档错误日志?

假设SQL Server实例从来没被重启过,也没有手动归档过错误日志,那么错误日志文件可能会变得很大,尤其是有内部错误时会DUMP很多信息,一来占空间,更重要的是:想要查看分析也会不太方便。

SQL Server/SQL Server Agent 错误日志有2种归档方式,即:创建一个新的日志文件,并将最老的日志删除。

(1) 自动归档:在SQL Server/ SQL Server Agent服务重启时;

(2) 手动归档:定期运行如下系统存储过程

EXEC master..sp_cycle_errorlog; --DBCC ERRORLOG 亦可
EXEC msdb.dbo.sp_cycle_agent_errorlog;--SQL Agent 服务需在启动状态下才有效

 

2.2 可不可以根据文件大小来归档?

可能有人会觉得,虽然很久没归档,但是错误日志确实不大,没必要定期归档,最好可以根据文件大小来判断。有以下几种方法:

(1) 有些监控工具,比如:SQL Diagnostic manager,就有检测错误日志文件大小,并根据大小来决定是否归档的功能;

(2) 自定义脚本也可以,比如:powershell, xp_enumerrorlogs 都可以检查错误日志大小;

(3) SQL Server 2012支持一个注册表选项,以下语句限制每个错误日志文件为5M,到了5M就会自动归档,在2008/2008 R2测试无效:

USE [master]
GO
EXEC xp_instance_regwrite N'HKEY_LOCAL_MACHINE', N'Software\Microsoft\MSSQLServer\MSSQLServer', N'ErrorLogSizeInKb', REG_DWORD, 5120;

 

. 错误日志查看及告警

错误日志以文本方式记录,记事本就可以查看,如果错误日志很大,可以选择Gvim/UltraEdit /DOS窗口type errorlog等,这些方式都会“分页”加载,不会卡住。

1. 错误日志查看

SQL Server提供了以下2种方式查看:

(1) 日志查看器 (log viewer),除了可以查看SQL Server 与SQL Server Agent的错误日志,还可以查看操作系统日志、数据库邮件日志。不过当日志文件太大时,图形界面非常慢;

(2) 未记载的扩展存储过程xp_readerrorlog,另外还有一个名为sp_readerrorlog的存储过程,它是对xp_readerrorlog的简单封装,并且只提供了4个参数,直接使用xp_readerrorlog即可:

在SQL Server 2000里,仅支持一个参数,即错误日志号,默认为0~6:

exec dbo.xp_readerrorlog   --写0或null都会报错,直接运行即可
exec dbo.xp_readerrorlog 1
exec dbo.xp_readerrorlog 6

 

--sql server 2000 read error log
if OBJECT_ID('tempdb..#tmp_error_log_all') is not null
    drop table #tmp_error_log_all

create table #tmp_error_log_all
(
info varchar(8000),--datetime + processinfo + text
num  int
)

insert into #tmp_error_log_all
exec dbo.xp_readerrorlog

--split error text
if OBJECT_ID('tempdb..#tmp_error_log_split') is not null
    drop table #tmp_error_log_split
create table #tmp_error_log_split
(
logdate      datetime,--datetime
processinfo  varchar(100),--processinfo
info         varchar(7900)--text
)

insert into #tmp_error_log_split
select CONVERT(DATETIME,LEFT(info,22),120),
       LEFT(STUFF(info,1,23,''),CHARINDEX(' ',STUFF(info,1,23,'')) - 1),
       LTRIM(STUFF(info,1,23 + CHARINDEX(' ',STUFF(info,1,23,'')),''))
  from #tmp_error_log_all
 where ISNUMERIC(LEFT(info,4)) = 1
   and info <> '.'
   and substring(info,11,1) = ' '

select * from #tmp_error_log_split where info like '%18456%'

 

在SQL Server 2005及以后版本里,支持多达7个参数,说明如下:

exec dbo.xp_readerrorlog 1,1,N'string1',N'string2',null,null,N'desc'

参数1.日志文件号: 0 = 当前, 1 = Archive #1, 2 = Archive #2, etc...

参数2.日志文件类型:  1 or NULL = SQL Server 错误日志, 2 = SQL Agent 错误日志

参数3.检索字符串1: 用来检索的字符串

参数4.检索字符串2:  在检索字符串1的返回结果之上再做过滤

参数5.日志开始时间

参数6.日志结束时间

参数7.结果排序: N'asc' = 升序, N'desc' = 降序

--sql server 2005 read error log
if OBJECT_ID('tempdb..#tmp_error_log') is not null
    drop table #tmp_error_log 

create table #tmp_error_log
(
logdate      datetime,
processinfo  varchar(100),
info         varchar(8000)
)

insert into #tmp_error_log
exec dbo.xp_readerrorlog

select *
  from #tmp_error_log
 where info like '%18456%'

 

2. 错误日志告警

可以通过对某些关键字做检索:错误(Error),警告(Warn),失败(Fail),停止(Stop),而进行告警 (database mail),以下脚本检索24小时内的错误日志:

declare 
     @start_time    datetime
    ,@end_time      datetime

set @start_time = CONVERT(char(10),GETDATE() - 1,120)
set @end_time = GETDATE()

if OBJECT_ID('tempdb..#tmp_error_log') is not null
    drop table #tmp_error_log

create table #tmp_error_log
(
logdate      datetime,
processinfo  varchar(100),
info         varchar(8000)
)

insert into #tmp_error_log
exec dbo.xp_readerrorlog 0,1,NULL,NULL,@start_time,@end_time,N'desc'

select COUNT(1) as num, MAX(logdate) as logdate,info 
  from #tmp_error_log
 where (info like '%ERROR%'
    or info like '%WARN%'
    or info like '%FAIL%'
    or info like '%STOP%')
   and info not like '%CHECKDB%'
   and info not like '%Registry startup parameters%'
   and info not like '%Logging SQL Server messages in file%'
   and info not like '%previous log for older entries%'
 group by info

当然,还可以添加更多关键字:kill, dead, victim, cannot, could, not, terminate, bypass, roll, truncate, upgrade, recover, IO requests taking longer than,但当中有个例外,就是DBCC CHECKDB,它的运行结果中必然包括Error字样,如下:

DBCC CHECKDB (xxxx) executed by sqladmin found 0 errors and repaired 0 errors.

所以对0 errors要跳过,只有在发现非0 errors时才作告警。

 

小结

如果没有监控工具,那么可选择扩展存储过程,结合数据库邮件的方式,作自动检查及告警,并定期归档错误日志文件以避免文件太大。大致步骤如下 :

(1) 部署数据库邮件;

(2) 部署作业:定时检查日志文件,如检索到关键字,发邮件告警;

(3) 部署作业:定期归档错误日志,可与步骤(2) 合并作为两个step放在一个作业里。

 

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
目录
相关文章
|
1天前
|
SQL 存储 缓存
高基数 GroupBy 在 SLS SQL 中的查询加速
本文详细介绍了SLS中的高基数GroupBy查询加速技术。
|
4天前
|
运维 Kubernetes 监控
Loki+Promtail+Grafana监控K8s日志
综上,Loki+Promtail+Grafana 监控组合对于在 K8s 环境中优化日志管理至关重要,它不仅提供了强大且易于扩展的日志收集与汇总工具,还有可视化这些日志的能力。通过有效地使用这套工具,可以显著地提高对应用的运维监控能力和故障诊断效率。
10 0
|
4天前
|
SQL 安全 数据库
基于SQL Server事务日志的数据库恢复技术及实战代码详解
基于事务日志的数据库恢复技术是SQL Server中一个非常强大的功能,它能够帮助数据库管理员在数据丢失或损坏的情况下,有效地恢复数据。通过定期备份数据库和事务日志,并在需要时按照正确的步骤恢复,可以最大限度地减少数据丢失的风险。需要注意的是,恢复数据是一个需要谨慎操作的过程,建议在执行恢复操作之前,详细了解相关的操作步骤和注意事项,以确保数据的安全和完整。
9 0
|
7天前
|
前端开发 C# 设计模式
“深度剖析WPF开发中的设计模式应用:以MVVM为核心,手把手教你重构代码结构,实现软件工程的最佳实践与高效协作”
【8月更文挑战第31天】设计模式是在软件工程中解决常见问题的成熟方案。在WPF开发中,合理应用如MVC、MVVM及工厂模式等能显著提升代码质量和可维护性。本文通过具体案例,详细解析了这些模式的实际应用,特别是MVVM模式如何通过分离UI逻辑与业务逻辑,实现视图与模型的松耦合,从而优化代码结构并提高开发效率。通过示例代码展示了从模型定义、视图模型管理到视图展示的全过程,帮助读者更好地理解并应用这些模式。
19 0
|
7天前
|
SQL 数据处理 数据库
|
7天前
|
SQL 存储 调度
|
7天前
|
SQL 安全 数据库
|
7天前
|
Java 数据库连接 数据库
告别繁琐 SQL!Hibernate 入门指南带你轻松玩转 ORM,解锁高效数据库操作新姿势
【8月更文挑战第31天】Hibernate 是一款流行的 Java 持久层框架,简化了对象关系映射(ORM)过程,使开发者能以面向对象的方式进行数据持久化操作而无需直接编写 SQL 语句。本文提供 Hibernate 入门指南,介绍核心概念及示例代码,涵盖依赖引入、配置文件设置、实体类定义、工具类构建及基本 CRUD 操作。通过学习,你将掌握使用 Hibernate 简化数据持久化的技巧,为实际项目应用打下基础。
22 0
|
7天前
|
SQL 存储 监控
|
16天前
|
SQL 关系型数据库 MySQL
【揭秘】MySQL binlog日志与GTID:如何让数据库备份恢复变得轻松简单?
【8月更文挑战第22天】MySQL的binlog日志记录数据变更,用于恢复、复制和点恢复;GTID为每笔事务分配唯一ID,简化复制和恢复流程。开启binlog和GTID后,可通过`mysqldump`进行逻辑备份,包含binlog位置信息,或用`xtrabackup`做物理备份。恢复时,使用`mysql`命令执行备份文件,或通过`innobackupex`恢复物理备份。GTID模式下的主从复制配置更简便。
69 2
下一篇
DDNS