sqlserver数据库锁定

⑴ 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 被锁表名

解锁：

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 blocked>0 ) a
where not exists(select * from (select * from sysprocesses where blocked>0 ) b
where a.blocked=spid)

--输出引起死锁的操作
DBCC INPUTBUFFER (@spid)
--查询当前进程数

select count(-1) from sysprocesses
where dbid in (select dbid from sysdatabases where name like '%telcount%');

⑵ sqlserver数据库ix是什么锁

ix是意向锁。
意向锁与其说是锁，倒不如说更像一个指示器。在SQL
Server中，资源是有层次的，一个表中可以包含N个页，而一个页中可以包含N个行。当我们在某一个行中加了锁时。可以理解成包含这个行的页，和表的一部分已经被锁定。当另一个查询需要锁定页或是表时，再一行行去看这个页和表中所包含的数据是否被锁定就有点太痛苦了。因此SQL
Server锁定一个粒度比较低的资源时，会在其父资源上加上意向锁，告诉其他查询这个资源的某一部分已经上锁。比如，当我们更新一个表中的某一行时，其所在的页和表都会获得意向排他锁，如图所示。

⑶ sqlserver数据库ix是什么锁

ix是意向锁。

意向锁与其说是锁，倒不如说更像一个指示器。在SQL Server中，资源是有层次的，一个表中可以包含N个页，而一个页中可以包含N个行。当我们在某一个行中加了锁时。可以理解成包含这个行的页，和表的一部分已经被锁定。当另一个查询需要锁定页或是表时，再一行行去看这个页和表中所包含的数据是否被锁定就有点太痛苦了。因此SQL Server锁定一个粒度比较低的资源时，会在其父资源上加上意向锁，告诉其他查询这个资源的某一部分已经上锁。比如，当我们更新一个表中的某一行时，其所在的页和表都会获得意向排他锁，如图所示。

⑷ 如何解除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在该语句执行完后释放这个锁，而如果同时指定了...(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的作用是允许用户先读取数据（而且不阻塞其他用户读数据），并且保证在后来再更新数据时，这一段时间内这些数据没有被其他用户修改。

⑸ 如何设置SQLServer数据库内存

如果能在实例级别为同一SQL服务器上的不同实例限制其能够使用的最大和最小内存，就能降低这种情况对启洞其他应用系统的影响。具体的操作如下：

（一）实例的最大和最小内存设置

右击数据库，选择属性，如图。

为实例设置合适的最大和最小内存，如图。

（二）为操作系统预留足够的内存

假如一台8GB的服务器，我们可以限制数据库使用的内存戚旁链上限不超过6GB，剩下的2GB留给操作系统使用。

（三）配置lockpagesinmemory

查看SQL进程的启动账户，如图。

在组策略里设置启动SQLServer的账户拥有锁定内存页的权限。如图。

在下图的添加用户高孙或组界面，添加SQLserver的服务启动账户，如图。

⑹ SQLServer与Oracle数据锁定的比较

数据库并行访问 也就是两个或两以上用户同时访问同一数据 这也是数据库引擎如何设计和实现适度反应所面临的最大问题 设计优良 性能卓越的数据库引擎可以轻松地同时为成千上万的正悄逗用户服务 而 底气不足 的数据库系统随着更多的用户同时访问系统将大大降低其性能 最糟糕的情况下甚至可能导致系统的崩溃

当然 并行访问是任何数据库解决方案都最为重视的问题了 为了解决并行访问方面的问题各类数据库系统提出了各种各样的方案 SQL Server和Oracle两大DBMS也分别采用了不同的并行处理方法 它们之间的实质差别在哪里呢？

并行访问的问题

并行访问出现问题存在若干种情况 在最简单的情形下 数量超过一个的用户可能同时查询同一数据 就这种情况而言数据库的操作目标很简单 尽可能地为用户们提供快速的数据访问 这对我们现在常见的数据库来说不成问题 SQL Server和 Oracle 都采用了多线程机制 它们当然能够一次处理多个请求

不过 在用户修改数据的情况下并行访问问题就变得复杂起来了 显然 数据库通常只允许唯一用户一次修改特定的数据 当某一用户开始修改某块数据时 SQL Server和 Oracle 都能很快地锁定数据 阻止其他用户对这块数据进行更新 直到修改该数据的第 位用户完成其操作并提交交易（mit transaction） 但是 当某一位用户正在修改某块数据时假设另一位用户又正想查询该数据的信息时会发生什么情况呢？在这种情况下数据库管理系统又该如何动作呢？Oracle 和 SQL Server针对这一问题采取运颂了不同的解决方案

SQL Server方法

现在不妨假设有人开始修改SQL Server上存储的数据 于是这块数据立即被数据库锁定 数据锁定操作阻塞其他任何访问该数据的连接——连查询操作都不会放过 于是 这块被锁定的数据只有在交易被提交或者回滚之后才能接受其他访问操作

下面用SQL Server随带的pubs示例数据库做一个简单示范 在Query Analyzer内打开两个窗口 在第 个窗口中执行下列SQL操作语句 更新pubs数据库中某一图书的价格

use pubs go begin tran update titles set price = price * where title_id = BU

由于代码中并没有执行mit语句 所以数据变动操作实际上还没有最终完成 接下来 在另一个窗口里执行下列语句查询titles数据表

select title_id title price from titles 举卖order by title_id

你什么结果也得不到 窗口底部的小地球图标会转个不停 尽管我在先前的操作中仅仅更新了一行 但是 select语句的执行对象却恰好包含了其数据正被修改的一行 因此 上面的操作不会返回任何数据 除非回到第 个窗口提交交易或者回滚

lishixin/Article/program/Oracle/201311/17702

⑺ 减少SQL Server数据库死锁的技巧

如果两个用户进程分别锁定了不同的资源 接着又试图锁定对方所锁定的资源 就会产生死锁 此时 SQL Server将自动地选择并中止其中一个进程以解除死锁 使得另外一个进程能够继续处理 系统将回退被中止的事务 并向被回退事务的用户发送错误信息 大多数设计良好的应用都会在接收到这个错误信息之后重新提交该事务 此时提交成功的可能性是很大的 但是 如果服务器上经常出现这种情况 就会显着地降低服务器性能 为避免死锁 设计应用应当遵循一定的原则 包括 ▲ 让应用每次都以相同的次序访问服务器资源 ▲ 在事务期间禁止任何用户输入 应当在事务开始之前收集用户输入 ▲ 尽量保持事务的短小和简单 ▲ 如合适的话 为运行事务的用户连接指定尽可能低的隔离级别 [适用于 ]此外 对于SQL Server的死锁问题 下面是几则实践中很有用的小技巧 ■ 使用SQL Server Profiler的Create Trace Wizard运行 Identify The Cause of a Deadlock 跟踪来辅助识别死锁问题 它将提供帮助查找数据库产生死锁原因的原始数据 [适用于 ]■ 如果无法消除应用中的所有死锁 请确保提供了这样一种程序逻辑 它能够在死锁出现并中止用户事务之后 以随机的时间间隔自动重新提交事务 这里等待时间的随机性非大销常重要 这是因为另一个竞争的事务也可能在等待 我们不应该让两个竞争的事务等待同样的时间 然后再在同一时间执行它们 这样的话将导致新的死锁 [适用于 ]■ 尽可能地简化所有T SQL事务 此举将减少各种类型的锁的数量 有助于提高SQL Server应用的整体性能 如果可能的话 应将较复杂的事务分割成多个较简单的事务 [适用于 ]■ 所有条件逻辑 变量赋值以及其他相关的预备设置操作应当在事务之外完成 而不应该放到事务之内 永远不要为了接受用户输入而暂停某个事务 用户输入应当总是在事务之外完成 [适用于 ]■ 在存储过程内封装所有事务 包括BEGIN TRANSACTION和MIT TRANSACTION语句 此举从两个方面帮助减少阻塞的锁 首先 它限制了事务运行时客户程序和SQL Server之间的通信 从而使得两者之间的任何消息只能出现于非事务运行时间（减少了事务运行的时间） 其次 由于存储过程强制它所启动的事务或者完成 或者中止 从而防止了用户留下未完成的事务（留下未撤销的锁） [适用于 ]■ 如果客户程序需要先用一定的时间贺瞎检查数据 然后可能更新数据 也可能不更新数据 那么最好不要在整个记录检查期间都锁定记录 假设大部分时间都是检查数据而不是更新数据 那么处理这种特殊情况的一种方法就是 先选择出记录（不加UPDATE子句 UPDATE子句将在记录上加上共享锁） 然后把它发送给客户 如果用户只查看记录但从来不更新它 程序可以什么也不做 反过来 如果用户决定更新某个记录 那么他可以通过一个WHERE子句检查当前的数据是否和以前提取的数据相同 然后执行UPDATE 类似地 我们还可以检查记录中的时间标识列（如果它存在的话） 如果数据相滚拍游同 则执行UPDATE操作 如果记录已经改变 则应用应该提示用户以便用户决定如何处理 虽然这种方法需要编写更多的代码 但它能够减少加锁时间和次数 提高应用的整体性能 [适用于 ]■ 尽可能地为用户连接指定具有最少限制的事务隔离级别 而不是总是使用默认的READ MITTED 为了避免由此产生任何其他问题 应当参考不同隔离级别将产生的效果 仔细地分析事务的特性 [适用于 ] ■ 使用游标会降低并发性 为避免这一点 如果可以使用只读的游标则应该使用READ_ONLY游标选项 否则如果需要进行更新 尝试使用OPTIMISTIC游标选项以减少加锁 设法避免使用SCROLL_LOCKS游标选项 该选项会增加由于记录锁定引起的问题 [适用于 ]■ 如果用户抱怨说他们不得不等待系统完成事务 则应当检查服务器上的资源锁定是否是导致该问题的原因 进行此类检查时可以使用SQL Server Locks Object: Average Wait Time (ms) 用该计数器来度量各种锁的平均等待时间 如果可以确定一种或几种类型的锁导致了事务延迟 就可以进一步探究是否可以确定具体是哪个事务产生了这种锁 Profiler是进行这类具体分析的最好工具 [适用于 ]■ 使用sp_who和sp_who （SQL Server Books Online没有关于sp_who 的说明 但sp_who 提供了比sp_who更详细的信息）来确定可能是哪些用户阻塞了其他用户 [适用于 ]■ 试试下面的一个或多个有助于避免阻塞锁的建议 ）对于频繁使用的表使用集簇化的索引 ）设法避免一次性影响大量记录的T SQL语句 特别是INSERT和UPDATE语句 ）设法让UPDATE和DELETE语句使用索引 ）使用嵌套事务时 避免提交和回退冲突 [适用于 ] lishixin/Article/program/SQLServer/201311/22222

⑻ 关于Sqlserver数据库 锁机制的小疑问，下种情况是否需要加入锁机制

不需要，就算确实用户同时执行，数据库的操作机制是有队列的，所以不存在并发情况。
锁基本用不到，我反正开发了5年了没用到过。
你要了解死锁发生的情况，一般是用事务的时候可能会碰到死锁，你申请了A资源，锁住了A然后申请B资源，其他人申请了B资源，然后申请A，这样就互不相让，导致A,B资源都不可访问了，不过其他数据我不知道，SQLSERVER发生这种死锁不是一直锁死的，过几分钟就会发现这个死锁，把锁释放掉，2个事务都失败。

⑼ sqlserver怎么实现一个行锁

1如何锁一个表的某一行


SELECT*FROMtableROWLOCKWHEREid=1

2锁定数据库的一个表

SELECT*FROMtableWITH(HOLDLOCK)

加锁语句：
sybase:
update表setcol1=col1where1=0;
MSSQL:
selectcol1from表(tablockx)where1=0;
oracle:
LOCKTABLE表INEXCLUSIVEMODE；
加锁后其它人不可操作，直到加锁用户解锁，用commit或rollback解锁