公司sqlserver的监控系统主要是采用zabbix监控,但是zabbix的监控只能通过性能计数器给出报警,而无法给出具体的阻塞情况,比如阻塞会话.语句.时间等,所以需要配合sqlserver的一些特性来进行监控,这里给出一个方案: 1.创建阻塞日志表,用于记录阻塞情况 2.新建作业,用于将阻塞情况记录到阻塞日志表中,并发送邮件(如果没有配置邮件,或者不需要发送邮件,可以忽略此步骤) 3.创建警报,当阻塞大于阈值时,触发上面作业 在数据库阻塞值大于阈值时,在原有zabbix的监控上,将阻塞报警

当某个数据库文件空间用尽,做自动增长的时候,同一时间点只能有一个用户人员可以做文件自动增长动作,其他任务必须等待,此时会出现Latch资源的等待.使用sp_helpdb查看业务数据库时发现:该数据库设置不合理,数据文件每次增长2M,日志文件每次增长10%,且分别设置了最大限制.修改为每次增长200M,不限制大小,系统恢复正常,问题解决. SqlServer阻塞时的等待类型如下: 顺便整理一下查看阻塞.会话状态及等待类型的SQL脚本: -- 查看SQL阻塞信息 with tmp as ( unio

背景:在sqlserver使用过程中经常由于各种原因会出现阻塞,并发数较高,很难肉眼看出那个session阻塞了其他process,通过sql查询出根源也需要大量的重复操作才能够找到. 因此就有这方面的需求来,通过session_id以及blocked_sessionid两个字段来找出阻塞根源并通过网页展示出来. echarts拥有非常优秀的BI组件库,能够对各种数据进行各种形式的展示. 前台部分代码为: <table> <tr> <td align="center

原文:第十六章--处理锁.阻塞和死锁(3)--使用SQLServer Profiler侦测死锁 前言: 作为DBA,可能经常会遇到有同事或者客户反映经常发生死锁,影响了系统的使用.此时,你需要尽快侦测和处理这类问题. 死锁是当两个或者以上的事务互相阻塞引起的.在这种情况下两个事务会无限期地等待对方释放资源以便操作.下面是死锁的示意图: 本文将使用SQLServer Profiler来跟踪死锁. 准备工作: 为了侦测死锁,我们需要先模拟死锁.本例将使用两个不同的会话创建两个事务. 步骤: 1. 打

公司sqlserver的监控系统主要是采用zabbix监控,但是zabbix的监控只能通过性能计数器给出报警,而无法给出具体的阻塞情况,比如阻塞会话.语句.时间等,所以需要配合sqlserver的一些特性来进行监控,这里给出一个方案: 1.创建阻塞日志表,用于记录阻塞情况 2.新建作业,用于将阻塞情况记录到阻塞日志表中,并发送邮件(如果没有配置邮件,或者不需要发送邮件,可以忽略此步骤) 3.创建警报,当阻塞大于阈值时,触发上面作业 在数据库阻塞值大于阈值时,在原有zabbix的监控上,将阻塞报警

经常会需要分析SQLSERVER的阻塞情况,尤其是某些SQL操作异常缓慢从而怀疑是有人在搞事情的情况下.网上有许多一模一样的帖子,是关于sp_who_lock这个存储过程的,然而,网上流传的这个是略有问题的(被阻塞的SQL输出有误),为此改造了一下实现,顺便优化了一下输出结构: CREATE PROCEDURE [dbo].[sp_who_lock] AS BEGIN DECLARE @spid INT , @bl INT , @intTransactionCountOnEntry INT ,

DDL/索引重建 会申请 Sch-M锁 with (nolock) 会申请 Sch-S锁 with (nolock)会阻塞 sch-M, 同样Sch-M也会 阻塞with (nolock) 索引重建2014后,增加 WAIT_AT_LOW_PRIORITY 参数,会检测当前是否存在阻塞事务,存在则中断当前索引重组操作. https://www.brentozar.com/archive/2015/01/testing-alter-index-rebuild-wait_at_low_priorit

查找阻塞进程: SELECT blocking_session_id '阻塞进程的ID', wait_duration_ms '等待时间(毫秒)', session_id '(会话ID)' FROM sys.dm_os_waiting_tasks 杀死阻塞进程: KILL 57

IF EXISTS (SELECT * FROM sysobjects WHERE [name] = 'sp_Lock_Scan') DROP PROCEDURE sp_Lock_Scan GO CREATE PROCEDURE sp_Lock_Scan AS DECLARE @SPID INT DECLARE @BLK INT DECLARE @Count INT DECLARE @Counter INT DECLARE @LOCK BIT CREATE TABLE #Temp ( [Id]

参考原文:http://blog.csdn.net/ha196200/article/details/44985597 (1) 数据库阻塞: 假设第一个连接T1占有且没有释放资源,第二个连接T2请求同一资源(表tb)时需要等待,若T1没有提交或回滚,T2将持续等待,导致阻塞发生. 第一个连接: begin tran 第二个连接: begin tran commit tran (2)  数据库死锁: 第一个连接占有资源没有释放,准备获取第二个连接所占用的资源,而第二个连接占有资源没有释放,准备获取

利用sys.sysprocesses SQL进程检查是否出现死锁和阻塞 Sys.SysProcesses 系统表是一个很重要的系统视图,主要用来定位与解决Sql Server的阻塞和死锁 select * from sys.sysprocesses      查看sql进程详细信息 select * from sys.syslockinfo          查看被锁住的对象 查看死锁进程 select spid, blocked, loginame, last_batch, status, c

select * from master.dbo.sysprocesses where DB_NAME(dbid)=’test’ and spid<>@@SPID 看看阻塞的进程 然后kill掉就行了 exec(‘kill ’ +@spid) 由于我是远程连接的数据库,杀死进程总会有顾虑.所以我就关闭了客户端,然后重启了之后就可以了. select显示我有两个进程一直处于runnable的状态 显示的是在执行SELECT

查询当前正在执行的语句 SELECT der.[session_id],der.[blocking_session_id], sp.lastwaittype,sp.hostname,sp.program_name,sp.loginame, der.[start_time] AS '开始时间', der.[status] AS '状态', dest.[text] AS 'sql语句', DB_NAME(der.[database_id]) AS '数据库名', der.[wait_type] AS

分享一个SQLSERVER脚本(计算数据库中各个表的数据量和每行记录所占用空间) 很多时候我们都需要计算数据库中各个表的数据量和每行记录所占用空间 这里共享一个脚本 CREATE TABLE #tablespaceinfo ( nameinfo ) , rowsinfo BIGINT , reserved ) , datainfo ) , index_size ) , unused ) ) ); DECLARE Info_cursor CURSOR FOR SELECT '[' + [name]

在生产环境中,会有很多使用ReadPast查询提示的场合,来避免正在被其它事务锁定的行对当前查询造成阻塞,而又不会获取到“脏数据”. 可是很多人都疑惑,为什么我使用了ReadPast仍然有时会被阻塞? 首先我们找到联机帮助: READPAST 指定数据库引擎不读取由其他事务锁定的行. 如果指定了 READPAST,将跳过行级锁. 也就是说,数据库引擎将跳过这些行,而不是阻塞当前事务直到锁被释放. 例如,假设表 T1 包含一个单精度整数列,其值为 1.2.3.4 和 5. 如果事务 A 将值 3

原文链接:http://www.cnblogs.com/caishuhua226/p/3838060.html   http://www.cnblogs.com/lyhabc/articles/2946938.html http://www.cnblogs.com/lipeng0824/p/4417581.html(还需要学习) 1)菜单路径:开始--程序--Microsoft SQL Server 2008--性能工具--SQL Server Profiler 或者在SSMS里打开,工具--S

SQLSERVER中的假脱机spool 我发现网上对于假脱机的解释都非常零散,究竟假脱机是什么? 这几天在家里研究了一下,收集了很多网上的资料 假脱机是中文的翻译,而英文的名字叫做 spool 在徐老师写的<SQLSERVER企业级平台管理实践>里提到了一下假脱机 在SQLSERVER I/O问题的那一节 在性能监视器里,有一个计数器“worktables/sec” : 每秒创建的工作表数.例如,工作表可用于存储查询假脱机(query spool),LOB变量,XML变量,表变量,游标的临时结

本文转载自:http://blog.csdn.net/andylaudotnet/article/details/1763573 性能调节的目的是通过将网络流通.磁盘 I/O 和 CPU 时间减到最小,使每个查询的响应时间最短并最大限度地提高整个数据库服务器的吞吐量.为达到此目的,需要了解应用程序的需求和数据的逻辑和物理结构,并在相互冲突的数据库使用之间(如联机事务处理 (OLTP) 与决策支持)权衡. 对性能问题的考虑应贯穿于开发阶段的全过程,不应只在最后实现系统时才考虑性能问题.许多使性能得

脏读:当一个事务开始更新数据,但是这个事务并没有完全提交,这个时候第二个事务开始读取数据,把第一个事务所更改的数据读了出来, 第二个事务读取的数据时临时的,因为有可能第一个事务最终有可能做回滚操作 不可重复读:在一个事务中多次读取某一行数据,可能会得到不同的结果 幻读:在一个事务中,我们读取数据,发现没有特定的行,第一个事务还没结束,这个时候第二个事务插入了该行数据, 然后在第一个事务再次读取时,该行数据突然出现了 SQLServer数据库支持一下隔离级别:未提交读.已提交读.可重复读.快照.可

From:http://www.cnblogs.com/mzhanker/archive/2011/06/04/2072739.html 使用sqlserver作为数据库的应用系统,都避免不了有时候会产生死锁, 死锁出现以后,维护人员或者开发人员大多只会通过sp_who来查找死锁的进程,然后用sp_kill杀掉.利用sp_who_lock这个存储过程,可以很方便的知道哪个进程出现了死锁,出现死锁的问题在哪里. 创建sp_who_lock存储过程 CREATE procedure sp_who_l