SqlServer异常处理常用步骤

SQL Server常见的问题主要是SQL问题造成,常见的主要是CPU过高和阻塞。

一、CPU过高的问题

1、查询系统动态视图查询执行时间长的sql语句

WITH ProcessCTE(blocked) AS ( SELECT spid FROM sys.sysprocesses WHERE cpu>500 ) SELECT distinct a.* FROM ( SELECT TEXT,AA.* FROM sys.sysprocesses AA CROSS APPLY sys.dm_exec_sql_text(AA.sql_handle) ) a JOIN ProcessCTE bucte WITH(NOLOCK) ON bucte.blocked=a.spid --where loginame = 'TCScenery' ORDER BY a.CPU

二、阻塞问题

1、查询系统动态视图查询阻塞的sql语句

WITH ProcessCTE(blocked) AS ( SELECT blocked FROM sys.sysprocesses WHERE blocked>0 union SELECT blocked FROM sys.sysprocesses WHERE blocked>0 ) SELECT distinct a.* FROM ( SELECT TEXT,AA.* FROM sys.sysprocesses AA CROSS APPLY sys.dm_exec_sql_text(AA.sql_handle) ) a JOIN ProcessCTE bucte WITH(NOLOCK) ON bucte.blocked=a.spid ORDER BY a.blocked

2、使用系统自带的存储过程

Sp_who2和sp_lock以及使用dbcc inputbuffer(spid) 也可以用来分析阻塞

sp_who可以返回如下信息: (可选参数LoginName, 或active代表活动会话数)
Spid         (系统进程ID)
status      (进程状态)
loginame  (用户登录名)
hostname(用户主机名)
blk           (阻塞进程的SPID)
dbname   (进程正在使用的数据库名)
Cmd        (当前正在执行的命令类型)

sp_who2除了显示上面sp_who的输出信息外,还显示下面的信息:  (可选参数LoginName, 或active代表活动会话数)
CPUTime           (进程占用的总CPU时间)
DiskIO              (进程对磁盘读的总次数)
LastBatch         (客户最后一次调用存储过程或者执行查询的时间)
ProgramName  (用来初始化连接的应用程序名称,或者主机名)

下面是sp_who的用法,sp_who2与此类似

A.列出全部当前进程

以下示例使用没有参数的 sp_who 来报告所有当前用户。

USE master; GO EXEC sp_who; GO

B.列出特定用户的进程

以下示例显示如何通过登录名查看有关单个当前用户的信息。

USE master; GO EXEC sp_who 'janetl'; GO

C.显示所有活动进程

USE master; GO EXEC sp_who 'active'; GO

D.显示会话 ID 标识的特定进程

USE master; GO EXEC sp_who '10' --specifies the process_id; GO

sp_lock用法说明

sp_lock [ [ @spid1 = ] 'session ID1' ] [ , [@spid2 = ] 'session ID2' ][ ; ]
[ @spid1 = ] 'session ID1'

来自用户想要锁定其信息的 sys.dm_exec_sessions 的数据库引擎会话 ID 号。 session ID1 的数据类型为 int,默认值为 NULL。 执行 sp_who 可获取有关该会话的进程信息。 如果未指定会话 ID1,则显示有关所有锁的信息。

[ @spid2 = ] 'session ID2'

来自 sys.dm_exec_sessions 的另一个数据库引擎会话 ID 号,该会话 ID 号可能与 session ID1 同时具有锁,并且用户也需要其有关信息。 session ID2 的数据类型为 int,默认值为 NULL。

在 sp_lock 结果集中,由 @spid1 和 @spid2 参数指定的会话所持有的每个锁都对应一行。 如果既未指定 @spid1 又未指定 @spid2,则结果集将报告当前在数据库引擎实例中处于活动状态的所有会话的锁。

列名

数据类型

说明

spid

smallint

请求锁的进程的数据库引擎会话 ID 号。

dbid

smallint

保留锁的数据库的标识号。 可以使用 DB_NAME() 函数来标识数据库。

ObjId

int

持有锁的对象的标识号。 可以在相关数据库中使用 OBJECT_NAME() 函数来标识对象。 值为 99 时是一种特殊情况,表示用于记录数据库中页分配的其中一个系统页的锁。

IndId

smallint

持有锁的索引的标识号。

类型

nchar(4)

锁的类型:

RID = 表中单个行的锁,由行标识符 (RID) 标识。

KEY = 索引内保护可串行事务中一系列键的锁。

PAG = 数据页或索引页的锁。

EXT = 对某区的锁。

TAB = 整个表(包括所有数据和索引)的锁。

DB = 数据库的锁。

FIL = 数据库文件的锁。

APP = 指定的应用程序资源的锁。

MD = 元数据或目录信息的锁。

HBT = 堆或 B 树索引的锁。 在 SQL Server 中此信息不完整。

AU = 分配单元的锁。 在 SQL Server 中此信息不完整。

Resource

nchar(32)

标识被锁定资源的值。 值的格式取决于 Type 列标识的资源类型:

Type 值:Resource 值

RID:格式为 fileid:pagenumber:rid 的标识符,其中 fileid 标识包含页的文件,pagenumber 标识包含行的页,rid 标识页上的特定行。 fileid 与sys.database_files 目录视图中的 file_id 列相匹配。

KEY:数据库引擎内部使用的十六进制数。

PAG:格式为 fileid:pagenumber 的数字,其中 fileid 标识包含页的文件,pagenumber 标识页。

EXT:标识区中的第一页的数字。 该数字的格式为 fileid:pagenumber。

TAB:没有提供信息,因为已在 ObjId 列中标识了表。

DB:没有提供信息,因为已在 dbid 列中标识了数据库。

FIL:文件的标识符,与 sys.database_files 目录视图中的 file_id 列相匹配。

APP:被锁定的应用程序资源的唯一标识符。 格式为 DbPrincipleId:<资源字符串的前 2 个到 16 个字符><哈希运算值>。

MD:随资源类型而变化。 有关详细信息,请参阅 sys.dm_tran_locks (Transact-SQL) 中 resource_description 列的说明。

HBT:没有提供任何信息。 请改用 sys.dm_tran_locks 动态管理视图。

AU:没有提供任何信息。 请改用 sys.dm_tran_locks 动态管理视图。

模式

nvarchar(8)

所请求的锁模式。 可以是:

NULL = 不授予对资源的访问权限。 用作占位符。

Sch-S = 架构稳定性。 确保在任何会话持有对架构元素(例如表或索引)的架构稳定性锁时,不删除该架构元素。

Sch-M = 架构修改。 必须由要更改指定资源架构的任何会话持有。 确保没有其他会话正在引用所指示的对象。

S = 共享。 授予持有锁的会话对资源的共享访问权限。

U = 更新。 指示对最终可能更新的资源获取的更新锁。 用于防止一种常见的死锁,这种死锁在多个会话锁定资源以便稍后对资源进行更新时发生。

X = 排他。 授予持有锁的会话对资源的独占访问权限。

IS = 意向共享。 指示有意将 S 锁放置在锁层次结构中的某个从属资源上。

IU = 意向更新。 指示有意将 U 锁放置在锁层次结构中的某个从属资源上。

时间: 2024-10-15 21:09:51

SqlServer异常处理常用步骤的相关文章

SqlServer异常处理常用步骤_MsSql

SQL Server常见的问题主要是SQL问题造成,常见的主要是CPU过高和阻塞. 一.CPU过高的问题 1.查询系统动态视图查询执行时间长的sql语句 WITH ProcessCTE(blocked) AS ( SELECT spid FROM sys.sysprocesses WHERE cpu>500 ) SELECT distinct a.* FROM ( SELECT TEXT,AA.* FROM sys.sysprocesses AA CROSS APPLY sys.dm_exec_

诊断SQLSERVER问题常用的日志概述及使用_MsSql

诊断SQLSERVER问题常用的日志 这里主要有两个: (1)Windows事件日志 (2)SQLSERVER ErrorLog 1.Windows事件日志 Event Log 作为一个Windows开启和管理的服务程序,Windows会在自己的系统日志system log里记录SQLSERVER这个服务的启动.正常关闭.异常关闭等信息. SQLSERVER也会把自己的一些概要信息同时记录在Windows的应用程序日志里Application Log而Windows日志本身又能够反映操作系统的健

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

诊断SQLSERVER问题常用的日志 这里主要有两个: (1)Windows事件日志 (2)SQLSERVER ErrorLog 1.Windows事件日志 Event Log 作为一个Windows开启和管理的服务程序,Windows会在自己的系统日志system log里记录SQLSERVER这个服务的启动.正常关闭.异常关闭等信息. SQLSERVER也会把自己的一些概要信息同时记录在Windows的应用程序日志里Application Log而Windows日志本身又能够反映操作系统的健

SQLServer管理常用SQL语句

server|sqlserver|语句 1. 查看数据库的版本        select @@version 2. 查看数据库所在机器操作系统参数        exec master..xp_msver 3. 查看数据库启动的参数         sp_configure 4. 查看数据库启动时间         select convert(varchar(30),login_time,120) from master..sysprocesses where spid=1 查看数据库服务器

SQLserver中常用日期时间函数

统计在数据库中是最常见也是必不可少的,前段时间用Teechat控件使用统计遇到的一些SQL语句整理一下,重点常用函数有datediff()和datepart(),下面大概讲述下这些函数.  代码如下 复制代码 1.一个月第一天的 Select DATEADD(mm, DATEDIFF(mm,0,getdate()), 0) 2.本周的星期一 Select DATEADD(wk, DATEDIFF(wk,0,getdate()), 0) 3.一年的第一天 Select DATEADD(yy, DA

sqlserver游标使用步骤示例(创建游标 关闭游标)_MsSql

游标(cursor)是一个存储在DBMS服务器上的数据库查询,它不是一条SELECT语句,而是被该语句检索出来的结果集.在存储了游标之后,应用程序可以根据需要滚动或浏览其中的数据. 使用游标 使用游标的步骤: 在使用游标前,必须声明(定义)它.这个过程实际上没有检索数据,它只是定义要使用的SELECT语句和游标选项.一旦声明,就必须打开游标以供使用.这个过程用前面定义的SELECT语句把数据实际检索出来.对于填有数据的游标,根据需要取出(检索)各行.在结束游标使用时,必须关闭游标,可能的话,释放

sqlserver游标使用步骤示例(创建游标 关闭游标)

游标(cursor)是一个存储在DBMS服务器上的数据库查询,它不是一条SELECT语句,而是被该语句检索出来的结果集.在存储了游标之后,应用程序可以根据需要滚动或浏览其中的数据. 使用游标 使用游标的步骤: 在使用游标前,必须声明(定义)它.这个过程实际上没有检索数据,它只是定义要使用的SELECT语句和游标选项.一旦声明,就必须打开游标以供使用.这个过程用前面定义的SELECT语句把数据实际检索出来.对于填有数据的游标,根据需要取出(检索)各行.在结束游标使用时,必须关闭游标,可能的话,释放

SQLServer 管理常用SQL语句_MsSql

1. 查看数据库的版本 select @@version 2. 查看数据库所在机器操作系统参数 exec master..xp_msver 3. 查看数据库启动的参数 sp_configure 4. 查看数据库启动时间 select convert(varchar(30),login_time,120) from master..sysprocesses where spid=1 查看数据库服务器名和实例名 print 'Server Name...............:' + conver

利用脚本自动安装SQLServer的实现步骤分析_MsSql

每当这种情况发生的时候,我总会心里默念道:杯具啊,这辈子也装不完了.因为SQL Server的安装还是比较复杂的,要先安装.Net.Windows Installer,在正式安装的过程中还要交互的填写各种参数,当然这个还不包括拷贝3GB多的安装文件的时间.在经历了几次这样的悲剧之后,我果断的意识到必须研究一下写个脚本改变这个残酷的现实. 前段时间会学校毕业答辩我终于暂时离开了繁重的工作,能找个时间研究一下脚本了.刚开始实验这个脚本的时候,由于同学喊我打游戏,我就偷懒没准备实验环境,直接用我的本子