锁表sqlserver,oracle锁表

怎样查询出SQLSERVER被锁的表，以锁表的SQL语句

查看被锁表：

select request_session_id spid,OBJECT_NAME(resource_associated_entity_id) tableName

from sys.dm_tran_locks where resource_type='OBJECT'

spid 锁表进程

tableName 被锁表名

相关问答

Q1: sqlserver跳过锁表等待

减少程序中 DML（insert，update，delete） 操作所花费的时间，对此类操作做好隔离控制，防止阻塞。如果事务产生异常，确保事务可以正常回滚。

通常情况下，数据库锁表大多是因为程序设计不合理导致的，在写代码的时候，我们要对业务场景充分考虑，尽量做到以下两点：减少程序中 DML（insert，update，delete） 操作所花费的时间，对此类操作做好隔离控制，防止阻塞。如果事务产生异常，确保事务可以正常回滚。

在数据库开发过程中，不得不考虑并发性的问题，因为很有可能当别人正在更新表中记录时，你又从该表中读数据，那你读出来的数据有可能就不是你希望得到的数据。可以说有些数据同时只能有一个事物去更新，否则最终显示给用户的数据不是数据库中现存的数据。锁表就限制不同的事物在同一时间内不允许同时操作一张表，实例很简单，可以用select来锁定整张表，那别人就不可能更新或是读取表的记录。

Q2: sqlserver怎么用sql查看具体那个表被锁住了

详细步骤如下：

1、点击【新建查询】按钮，打开SQL命令编辑框，对数据库表的操作以及维护都可以通过编辑SQL命令实现。

2、在编辑框内编辑创建数据库表的代码，确认代码无误后，单击【执行】按钮，创建数据表。

3、创建数据表的源代码如下：

use test go

if exists(select name from sys.tables where name='Student')

drop table Student go

create table Student

(sname nchar(10) primary key,

sex nchar(2) not null,

bir datetime)

数据库管理系统，database management system，简称dbms，是一种操纵和管理数据库的大型软件，用于建立、使用和维护数据库。用户通过dbms访问数据库中的数据，数据库管理员也通过dbms进行数据库的维护工作。它可使多个应用程序和用户用不同的方法在同时或不同时刻去建立，修改和询问数据库。

提供数据定义语言（ddl）。用它书写的数据库模式被翻译为内部表示。数据库的逻辑结构、完整性约束和物理储，存结构保存在内部的数据字典中。数据库的各种数据操作（如查找、修改、插入和删除等）和数据库的维护管理都是以数据库模式为依据的。

Q3: 锁表怎么解决 sql server

查看被锁表：

select request_session_id spid,OBJECT_NAME(resource_associated_entity_id) tableName

from sys.dm_tran_locks where resource_type='OBJECT'

--spid 锁表进程

--tableName 被锁表名

解锁：

declare @spid int

Set @spid = 57 --锁表进程

declare @sql varchar(1000)

set @sql='kill '+cast(@spid as varchar)

exec(@sql)

--查询出死锁的SPID

select blocked

from (select * from sysprocesses where blocked0 ) a

where not exists(select * from (select * from sysprocesses where blocked0 ) b

where a.blocked=spid)

--输出引起死锁的操作

DBCC INPUTBUFFER (@spid)

--查询当前进程数

select count(-1) from sysprocesses

where dbid in (select dbid from sysdatabases where name like '%telcount%');

Q4: SQL Server表锁定原理以及如何解除锁定

1. 数据库表锁定原理

1.1 目前的C/S,B/S结构都是多用户访问数据库,每个时间点会有成千上万个user来访问DB,其中也会同时存取同一份数据,会造成数据的不一致性或者读脏数据.

1.2 事务的ACID原则

1.3 锁是关系数据库很重要的一部分, 数据库必须有锁的机制来确保数据的完整和一致性.

1.3.1 SQL Server中可以锁定的资源:

1.3.2 锁的粒度:

1.3.3 锁的升级:

锁的升级门限以及锁升级是由系统自动来确定的，不需要用户设置.

1.3.4 锁的类型:

(1) 共享锁:

共享锁用于所有的只读数据操作.

(2) 修改锁:

修改锁在修改操作的初始化阶段用来锁定可能要被修改的资源，这样可以避免使用共享锁造成的死锁现象

(3) 独占锁:

独占锁是为修改数据而保留的。它所锁定的资源，其他事务不能读取也不能修改。独占锁不能和其他锁兼容。

(4) 架构锁

结构锁分为结构修改锁（Sch-M）和结构稳定锁（Sch-S）。执行表定义语言操作时，SQL Server采用Sch-M锁，编译查询时，SQL Server采用Sch-S锁。

(5) 意向锁

意向锁说明SQL Server有在资源的低层获得共享锁或独占锁的意向。

(6) 批量修改锁

批量复制数据时使用批量修改锁

1.3.4 SQL Server锁类型

(1) HOLDLOCK: 在该表上保持共享锁，直到整个事务结束，而不是在语句执行完立即释放所添加的锁。

(2) NOLOCK：不添加共享锁和排它锁，当这个选项生效后，可能读到未提交读的数据或“脏数据”，这个选项仅仅应用于SELECT语句。

(3) PAGLOCK：指定添加页锁（否则通常可能添加表锁）。　

(4) READCOMMITTED用与运行在提交读隔离级别的事务相同的锁语义执行扫描。默认情况下，SQL Server 2000 在此隔离级别上操作。

(5) READPAST: 跳过已经加锁的数据行，这个选项将使事务读取数据时跳过那些已经被其他事务锁定的数据行，而不是阻塞直到其他事务释放锁，

READPAST仅仅应用于READ COMMITTED隔离性级别下事务操作中的SELECT语句操作。　

(6) READUNCOMMITTED：等同于NOLOCK。　

(7) REPEATABLEREAD：设置事务为可重复读隔离性级别。　

(8) ROWLOCK：使用行级锁，而不使用粒度更粗的页级锁和表级锁。

(9) SERIALIZABLE：用与运行在可串行读隔离级别的事务相同的锁语义执行扫描。等同于 HOLDLOCK。　

(10) TABLOCK：指定使用表级锁，而不是使用行级或页面级的锁，SQL Server在该语句执行完后释放这个锁，而如果同时指定了HOLDLOCK，该锁一直保持到这个事务结束。 (11) TABLOCKX：指定在表上使用排它锁，这个锁可以阻止其他事务读或更新这个表的数据，直到这个语句或整个事务结束。　

(12) UPDLOCK ：指定在

读表中数据时设置更新 锁（update lock）而不是设置共享锁，该锁一直保持到这个语句或整个事务结束，使用UPDLOCK的作用是允许用户先读取数据（而且不阻塞其他用户读数据），并且保证在后来再更新数据时，这一段时间内这些数据没有被其他用户修改。

2. 如何解除表的锁定,解锁就是要终止锁定的那个链接,或者等待该链接事务释放.

2.1 Activity Monitor

可以通过Wait Type, Blocked By栏位查看到,SPID 54 被SPID 53 阻塞. 可以右键Details查到详细的SQL 语句,或Kill掉这个进程.

2.2 SQL Server提供几个DMV,查看locks

sys.dm_exec_requests

sys.dm_tran_locks

sys.dm_os_waiting_tasks

sys.dm_tran_database_transactions

(1)

select * from sys.dm_tran_locks where  resource_type'DATABASE' --and resource_database_id=DB_ID()

(2)

SELECT session_id, blocking_session_id,*

FROM sys.dm_exec_requests

WHERE blocking_session_id  0

(3)代码

SELECT

request_session_id as Spid,

Coalesce(s.name + '.' + o.name + isnull('.' + i.name,''),

s2.name + '.' + o2.name,

db.name) AS Object,

l.resource_type as Type,

request_mode as Mode,

request_status as Status

FROM sys.dm_tran_locks l

LEFT JOIN sys.partitions p

ON l.resource_associated_entity_id = p.hobt_id

LEFT JOIN sys.indexes i

ON p.object_id = i.object_id

AND p.index_id = i.index_id

LEFT JOIN sys.objects o

ON p.object_id = o.object_id

LEFT JOIN sys.schemas s

ON o.schema_id = s.schema_id

LEFT JOIN sys.objects o2

ON l.resource_associated_entity_id = o2.object_id

LEFT JOIN sys.schemas s2

ON o2.schema_id = s2.schema_id

LEFT JOIN sys.databases db

ON l.resource_database_id = db.database_id

WHERE resource_database_id = DB_ID()

ORDER BY Spid, Object, CASE l.resource_type

When 'database' Then 1

when 'object' then 2

when 'page' then 3

when 'key' then 4

Else 5 end

Q5: sqlserver锁表机制

这个问题要具体分析：

第一，事务隔离级别基本两种模式，一种是阻塞式（read committed，repeatable read，serializable）

，一种是非阻塞式(read uncommitted,snapshot)。

默认是read committed，这种情况一般在更新表的时候，如果不使用hint 提示，基本是先对表添加IX锁，级别不算高，基本和其他锁兼容，但是repeatable read，serializable 事务隔离级别就会先对表添加IX锁，然后向X锁转化，而X锁和大多数锁都不兼容，容易发生表阻塞。

第二种隔离级别不会有以上问题，但是又引入了其它的问题。

以上是一种情况。

另外一种就是 锁升级，一个锁是96B内存，如果太多，sqlserver就会升级为表锁，一般是5000以上行级锁就升级为一个表X锁。

所以适当的文件分组和表分区 是有必要的。

其次就是资源互相引用导致事务长时间不能释放，导致真正的死锁，不过SQL2005以后，这种情况发生的概率很低。

留个问题你自己去想。

两个SQL，两个连接，同时执行。

update A set A.NAME=xxx where A.id=55

update A set A.NAME=xxx where A.id=56, 如果 56 不存在你说会发生什么情况呢？