加入收藏 | 设为首页 | 会员中心 | 我要投稿 财气旺网 - 财气网 (https://www.caiqiwang.com/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 站长学院 > MsSql教程 > 正文

sql-server – 我可以从SQL Server默认获得哪些事件信息?

发布时间:2020-12-31 12:21:08 所属栏目:MsSql教程 来源:网络整理
导读:我经常会看到一些问题,人们想知道某件事情是否发生,或者何时发生,或者是谁执行了这一行动.在很多情况下,SQL Server本身不会跟踪此信息.例如: 谁最后执行了存储过程dbo.MyProcedure? 谁更新了dbo.Employees表中的salary列? 谁最后查询了Management Studio的

>遇到严重性为> = 20的错误的任何会话的sql_text和session_id
>遇到“内存”类型错误的任何会话的sql_text和session_id,如17803,701等(我们添加了这个,因为并非所有内存错误都是严重性> = 20)
>任何“非屈服”问题的记录(您有时在ERRORLOG中看到这些问题为Msg 17883)
>检测到的任何死锁
>对于等待锁定(或其他有趣资源)的任何会话的callstack,sql_text和session_id,用于> 15秒
>任何等待锁定的会话的callstack,sql_text和session_id为> 30秒
>任何会话的callstack,等待“外部”等待或“先发制人等待”的延长时间.

从Use the system_health event session (MSDN)开始,该列表在SQL Server 2012中有所扩展(对于SQL Server 2014仍然保持不变):

>遇到严重性> gt = 20的错误的任何会话的sql_text和session_id.
>遇到与内存相关的错误的任何会话的sql_text和session_id.错误包括17803,701,802,8645,8651,8657和8902.
>任何非屈服调度程序问题的记录. (它们在SQL Server错误日志中显示为错误17883.)
>检测到的任何死锁.
>对于等待锁定(或其他有趣资源)的任何会话的callstack,用于> 15秒
>任何已等待>锁定的会话的callstack,sql_text和session_id 30秒.
>用于抢占等待很长时间的任何会话的callstack,sql_text和session_id.持续时间因等待类型而异.抢先等待是SQL Server等待外部API调用的地方.
>用于CLR分配和虚拟分配失败的callstack和session_id.
>内存代理,调度程序监视器,内存节点OOM,安全性和连接的ring_buffer事件.
> sp_server_diagnostics的系统组件结果.
> scheduler_monitor_system_health_ring_buffer_recorded收集的实例运行状况.
> CLR分配失败.
>使用connectivity_ring_buffer_recorded的连接错误.
>使用security_error_ring_buffer_recorded的安全错误.

在SQL Server 2016中,还捕获了另外两个事件:

>使用KILL命令终止进程时.
> SQL Server关闭时已启动.

(该文档尚未更新,but I blogged about how I discover these and other changes.)

要获得适用于特定版本的更加神秘的配置,您始终可以直接运行以下查询,但是您必须解释名称并解析谓词以匹配上面更自然的语言列表:

SELECT e.package,e.event_id,e.name,e.predicate
  FROM sys.server_event_session_events AS e
  INNER JOIN sys.server_event_sessions AS s
  ON e.event_session_id = s.event_session_id
 WHERE s.name = N'system_health'
 ORDER BY e.package,e.name;

如果您正在使用可用性组,则还会发现两个正在运行的新会话:AlwaysOn_failover和AlwaysOn_health.您可以使用以下查询查看他们收集的数据:

SELECT s.name,e.package,e.predicate
  FROM sys.server_event_session_events AS e
  INNER JOIN sys.server_event_sessions AS s
  ON e.event_session_id = s.event_session_id
 WHERE s.name LIKE N'AlwaysOn[_]%'
 ORDER BY s.name,e.name;

这些事件会话使用环形缓冲区目标来存储数据,因此 – 如缓冲池和计划缓存 – 旧事件将逐步淘汰,因此您不一定能够从所需的日期范围中提取事件.

在这个问题中我提出了这个虚构的问题:

How many memory-related errors have happened today?

以下是可以从system_health会话中提取此信息的示例(可能不是非常高效)查询:

;WITH src(x) AS
(
  SELECT y.query('.')
  FROM
  (
    SELECT x = CONVERT(XML,t.target_data)
      FROM sys.dm_xe_sessions AS s
      INNER JOIN sys.dm_xe_session_targets AS t
      ON s.[address] = t.event_session_address
      WHERE s.name = N'system_health'
  ) AS x
  CROSS APPLY x.x.nodes('/RingBufferTarget/event') AS y(y)
)
SELECT 
  x,ts = CONVERT(DATETIME,NULL),err = CONVERT(INT,NULL)
INTO #blat FROM src;

DELETE #blat WHERE x.value('(/event/@name)[1]','varchar(255)') <> 'error_reported';

UPDATE #blat SET ts = x.value('(/event/@timestamp)[1]','datetime');

UPDATE #blat SET err = x.value('(/event/data/value)[1]','int');

SELECT err,number_of_events = COUNT(*)
  FROM #blat
  WHERE err IN (17803,8657,8902)
  AND ts >= CONVERT(DATE,CURRENT_TIMESTAMP)
  GROUP BY err;

DROP TABLE #blat;

(这个例子从Amit Banerjee’s introductory blog post on the system_health session开始宽容借用.)

有关扩展事件的更多信息(包括可以查询特定数据的许多示例),请参阅Jonathan Kehayias撰写的这个由31部分组成的博客系列:

https://www.sqlskills.com/blogs/jonathan/an-xevent-a-day-31-days-of-extended-events/

错误日志

SQL Server默认保留当前加上6个最新的错误日志文件(但是you can change this).存储了大量信息,包括启动信息(正在使用的内核数量,内存中的锁定页面是否设置,身份验证模式等)以及错误和其他严重到足以记录的情况(并且未在其他地方捕获).最近的一个例子是有人在数据库脱机时寻找.您可以通过扫描每个最新的7个错误日志来确定文本设置数据库选项OFFLINE:

EXEC sys.sp_readerrorlog 0,1,'Setting database option OFFLINE';
EXEC sys.sp_readerrorlog 1,'Setting database option OFFLINE';
EXEC sys.sp_readerrorlog 2,'Setting database option OFFLINE';
EXEC sys.sp_readerrorlog 3,'Setting database option OFFLINE';
EXEC sys.sp_readerrorlog 4,'Setting database option OFFLINE';
EXEC sys.sp_readerrorlog 5,'Setting database option OFFLINE';
EXEC sys.sp_readerrorlog 6,'Setting database option OFFLINE';

我介绍了其他一些细节in this recent answer,还有一些很好的背景信息at toadworld和in the official documentation.

默认情况下,错误日志会跟踪一组“错误” – 并且可以使重要信息更快地脱离 – 是每个成功的备份消息.您可以在enabling trace flag 3226之前阻止这些错误日志填满噪音.

(编辑:财气旺网 - 财气网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

热点阅读