SQL Server 死锁的告警监控

原文:SQL Server 死锁的告警监控

今天这篇文章总结一下如何监控SQL Server的死锁,其实以前写过MS SQL 监控错误日志的告警信息,这篇文章着重介绍如何监控数据库的死锁,当然这篇文章不分析死锁产生的原因、以及如何解决死锁。死锁(Dead Lock)的错误信息在sys.messages中的message_id为1205,可以使用下面SQL查看。

SELECT * FROM sys.messages WHERE message_id=1205

那么接下来,我们来设置一下死锁(Dead Lock)告警吧, 如下所示,当然你可以使用UI界面设置。

 
USE [msdb]

GO

 

IF NOT EXISTS(SELECT 1 FROM msdb.dbo.syscategories WHERE NAME=‘DBA_MONITORING‘ AND category_class=2)

BEGIN

 

EXEC msdb.dbo.sp_add_category

    @class=N‘ALERT‘,

    @type=N‘NONE‘,

    @name=N‘DBA_MONITORING‘ ;

 

END

GO

 

IF EXISTS(SELECT 1 FROM msdb.dbo.sysalerts WHERE name=‘SQL Server Dead Lock Detected‘)

BEGIN

    EXEC msdb.dbo.sp_delete_alert @name=N‘SQL Server Dead Lock Detected‘;

END

GO

 

 

IF NOT EXISTS(SELECT 1 FROM msdb.dbo.sysalerts WHERE name=‘SQL Server Dead Lock Detected‘)

BEGIN

EXEC msdb.dbo.sp_add_alert @name=N‘SQL Server Dead Lock Detected‘, 

        @message_id=1205, 

        @severity=0, 

        @enabled=1, 

        @delay_between_responses=0, 

        @include_event_description_in=1, 

        @category_name=N‘DBA_MONITORING‘, 

        @job_id=N‘00000000-0000-0000-0000-000000000000‘

END

GO

 

IF NOT EXISTS ( SELECT  *

                FROM    msdb.dbo.sysnotifications

                WHERE   alert_id = ( SELECT id

                                     FROM   msdb.dbo.sysalerts

                                     WHERE  name = ‘SQL Server Dead Lock Detected‘

                                   ) )

    BEGIN

 

        EXEC msdb.dbo.sp_add_notification @alert_name = N‘SQL Server Dead Lock Detected‘,

            @operator_name = N‘YourSQLDba_Operator‘, @notification_method = 1;

    END;

GO

执行上面脚本后,就会在SQL Server的告警里面新增一个名为SQL Server Dead Lock Detected‘的告警,那么现在是否OK了呢?当然不是,我们来测试验证一下吧,首先准备测试的表和数据。

USE YourSQLDba;

GO

CREATE TABLE DEADLOCK1(ID INT DEFAULT(0));

CREATE TABLE DEADLOCK2(ID INT DEFAULT(0));

INSERT INTO DEADLOCK1 VALUES(1);

INSERT INTO DEADLOCK2 VALUES(1);

GO

如下所示,在两个会话窗口执行下面脚本,构造死锁出现的场景。

--会话窗口1执行下面SQL

BEGIN TRAN

UPDATE DEADLOCK1 SET ID=ID+1;

WAITFOR DELAY ‘00:00:20‘;

SELECT * FROM DEADLOCK2

ROLLBACK TRAN;

EXEC master..sp_altermessage 1205, ‘WITH_LOG‘, TRUE;

GO

--会话创建2执行下面SQL

BEGIN TRAN

UPDATE DEADLOCK2 SET ID=ID+1;

WAITFOR DELAY ‘00:00:20‘;

SELECT * FROM DEADLOCK1

ROLLBACK TRAN;

如下截图所示,当死锁出现后,那么这个告警设置是否会发送邮件出来呢? 答案是否定的,你可以检查告警的历史情况,如下所示:

从History界面,我们可以看到这个告警没有被触发,那么这个是什么原因呢?原因其实很简单,因为message_id为1205的消息字段is_event_logged默认是0,这意味着出现错误消息将不会记入事件日志。我们可以使用小SQL将其值设置为1

EXEC master..sp_altermessage 1205, ‘WITH_LOG‘, TRUE;

GO

执行上面脚本后,message_id为1205的记录的is_event_logged字段值将被设置为1,当数据库出现死锁时,就会被记录到错误日志,当然这个只是简单消息的记录,如果你要跟踪、解决死锁问题,就需要记录死锁的详细信息,需要在服务端针对所有的Session开启Trace flag 1222。

DBCC TRACEON(1222,-1);

原文地址:https://www.cnblogs.com/lonelyxmas/p/9411370.html

时间: 2024-11-02 14:31:58

SQL Server 死锁的告警监控的相关文章

Update导致SQL Server死锁的典型方法(转载)

此文为转载文章,描述的很好,没有验证过. 最近遇到了一个看上去很奇怪,分析起来很有意思的死锁问题.这个死锁看上去难以理解.而分析过程中,又使用了很多分析SQL Server死锁的典型方法.记录下来整个分析过程还是很有意义的. 问题重现步骤: 经过提炼,问题重现的步骤非常简单,在SQL 2008上可以很容易地重现. 1.         首先,创建一张表格,上面有一个clustered index,两个non-clustered index. create table tt(id int iden

SQL Server死锁产生原因及解决办法

SQL Server死锁产生原因及解决办法 2006-07-18 05:12:10 分类: SQL Server 其实所有的死锁最深层的原因就是一个:资源竞争 表现一: 一个用户A 访问表A(锁住了表A),然后又访问表B,另一个用户B 访问表B(锁住了表B),然后企图访问表A,这时用户A由于用户B已经锁住表B,它必须等待用户B释放表B,才能继续,好了他老人家就只好老老实实在这等了,同样用户B要等用户A释放表A才能继续这就死锁了. 解决方法: 这种死锁是由于你的程序的BUG产生的,除了调整你的程序

SQL Server 死锁 (Page锁)诊断

在数据库中打开死锁监测可以收集到数据库发生的死锁情况.打开的方式有2种: 1 打开1222监控 执行SQL语句: Dbcc traceon(1222,-1); 然后在系统日志里查看死锁的信息. 2 启动SQL Profiler(建议使用): 下面就是一个发生死锁的实例图: 下面提供对这个死锁分析思路,如有不当之处,还望大家批评指正. 一共3个问题,下面逐个回答. 第一个问题:被锁定的资源是什么? 上面写的很清楚,是一个Page 锁, 那么Page 锁是什么呢? 通常死锁是你操作A表,然后又要操作

SQL Server死锁排查

1. 死锁原理 根据操作系统中的定义:死锁是指在一组进程中的各个进程均占有不会释放的资源,但因互相申请被其他进程所站用不会释放的资源而处于的一种永久等待状态. 死锁的四个必要条件:互斥条件(Mutual exclusion):资源不能被共享,只能由一个进程使用.请求与保持条件(Hold and wait):已经得到资源的进程可以再次申请新的资源.非剥夺条件(No pre-emption):已经分配的资源不能从相应的进程中被强制地剥夺.循环等待条件(Circular wait):系统中若干进程组成

SQL Server死锁的分析、处理与预防

1. 基本原理 所谓"死锁",在操作系统的定义是:在一组进程中的各个进程均占有不会释放的资源,但因互相申请被其他进程所站用不会释放的资源而处于的一种永久等待状态. 定义比较抽象,下图可以帮助你比较直观的理解死锁: 出现死锁需要满足几个必要条件: a)互斥:进程独占资源,资源不共享: b)请求与保持:已经得到资源的进程可以再次申请新资源: c)不剥夺:已分配的资源不能被其它进程强制剥夺: d)环路等待:几个进程组成环路,都在相互等待正被占用的资源: 对应到SQL Server中,在2个或

SQL Server死锁总结

1. 死锁原理 根据操作系统中的定义:死锁是指在一组进程中的各个进程均占有不会释放的资源,但因互相申请被其他进程所站用不会释放的资源而处于的一种永久等待状态. 死锁的四个必要条件:互斥条件(Mutual exclusion):资源不能被共享,只能由一个进程使用.请求与保持条件(Hold and wait):已经得到资源的进程可以再次申请新的资源.非剥夺条件(No pre-emption):已经分配的资源不能从相应的进程中被强制地剥夺.循环等待条件(Circular wait):系统中若干进程组成

Sql server 死锁排查

记得以前客户在使用软件时,有偶发出现死锁问题,因为发生的时间不确定,不好做问题的重现,当时解决问题有点棘手了. 现总结下查看死锁的常用二种方式: 第一种是图形化监听: sqlserver -->工具--> sql server profiler   登录后在跟踪属性中选择如下图: 监听到的死锁图形如下图 这里的描述大致是:有二个进程 一个进程ID是96, 另一个ID是348.   系统自动kill 掉了进程ID:96,保留了进程ID:348 的事务Commit 原文地址:https://www

sql server 死锁自动释放

在高并发时数据库发生会死锁,发生死锁后,数据库会自动释放 原文: When a transaction is chosen as a deadlock victim, SQL Server will rollback the victim's transaction which releases locks held by the transaction. This will allow other transactions to proceed. Unlike blocking, deadlo

SQL Server死锁的解决过程

某现场报一个SQL死锁,于是开启了1222跟踪: dbcc traceon(1222,-1) 一段时间之后拷贝ERROR文件查找相关信息,比较有用的摘录出来如下: 语句一: select study_iuid,station_aet,modality,accession_no,patient_fk,item_attrs,start_datetime from worklist w WITH(readpast), mwl_item m where w.TAG_STUDY_INSTANCE_UID=