⑴ 怎么能查到造成锁等待的sql语句
sql server：
Select * from sysprocesses where blocked<>0
--找到SPID
exec sp_lock
--根据SPID找到OBJID
select object_name(85575343)
--根据OBJID找到表名
Oracle：
SELECT P.SPID,
A.SERIAL#,
C.OBJECT_NAME,
B.SESSION_ID,
B.ORACLE_USERNAME,
B.OS_USER_NAME
FROM V$PROCESS P,
V$SESSION A,
V$LOCKED_OBJECT B,
ALL_OBJECTS C
WHERE P.ADDR = A.PADDR
AND A.PROCESS = B.PROCESS
AND C.OBJECT_ID = B.OBJECT_ID;
⑵ SQL更新语句执行很久都不行,语法没错
查询一下，是否有死锁的情况，
这个表被锁了，或者 这部分数据页面 被锁了。
就是别人在 修改这个数据或者这个表的其他数据，一直没有提交啊什么的。
导致你的修改一直在等待。
⑶ plsql,做update操作,没有submit,表一直被锁3个小时,请问有没有办法在锁一定时间后自动释放锁
Oracle 11g has a problem that is session timeout problem. You can add a row to sqlnet.ora file and listener.ora file to resolve session timeout problem.
sqlnet.ora
Note : Add this line to below of sqlnet.ora file.
INBOUND_CONNECT_TIMEOUT=3600
listener.ora
Note : Add this line to below of listener.ora file.
INBOUND_CONNECT_TIMEOUT_LISTENER=2400
基本上这样可以解决session超时就会被kill掉
⑷ 当你在更新某条数据时，怎么用SQL语句锁定而不让别人同时更新 请知道的说下。 谢谢了
你更新的时候，你更新的数据上本身就加了排他锁的，在你更新的这段时间其他人无法再修改数据。或者还有别的操作后再释放这些数据的话可以用事务。
⑸ sql server里update时，是行锁还是表锁问题
看表结构,如果没有主键无法只锁定行
如果要验证的话,只需要类似下面的方法就行了:
--开事务,以保持锁
BEGINTRAN
--更新
updatetablea
setcolumn1=1
whereidx=1
--列出锁信息
EXECsp_lock@@spid
--提交或者回滚事务
COMMIT/ROLLBACKTRAN
输出的结果大致是这样:
通过dbid,ObjId可以找到你更新的表相关的锁记录
如果IndId为0,表示锁在表上,否则在对应的索引上
通过Type列,可以确定被锁定的是行/表,或者是其他,并且可以通过Mode看到是什么锁
在Status中,还可以看到锁是已经加上了,还是在等待其他资源释放(以取得加锁的权利)
-------------------------------------------------------------------------
53111151510180TABISGRANT
锁的类型(Tyep列值,RID和KEY的话,表示锁在行上)有如下几种：
RID=表中单个行的锁，由行标识符(RID)标识。
KEY=索引内保护可串行事务中一系列键的锁。
PAG=数据页或索引页的锁。
EXT=对某区的锁。
TAB=整个表（包括所有数据和索引）的锁。
DB=数据库的锁。
FIL=数据库文件的锁。
APP=指定的应用程序资源的锁。
MD=元数据或目录信息的锁。
HBT=堆或B树索引的锁。在SQLServer2005中此信息不完整。
AU=分配单元的锁。在SQLServer2005中此信息不完整。
⑹ SQL SERVER 数据是不是查询时用数据锁那更新(update)可以带锁吗
处理多用户并发访问的方法是加锁。锁是防止其他事务访问指定的资源控制、实现并发控制的一种主要手段。行是可以锁定的最小空间, 行级锁占用的数据资源最少，所以在事务的处理过程中，允许其他事务继续操纵同一个表或者同一个页的其他数据，大大降低了其他事务等待处理的时间，提高了系统的并发性。为了使锁定的成本减至最少，SQL Server 自动将资源锁定在适合任务的级别。锁定在较小的粒度（例如行）可以增加并发但需要较大的开销，因为如果锁定了许多行，则需要控制更多的锁。
行级锁是一种最优锁，因为行级锁不可能出现数据既被占用又没有使用的浪费现象。但是，如果用户事务中频繁对某个表中的多条记录操作，将导致对该表的许多记录行都加上了行级锁，数据库系统中锁的数目会急剧增加，这样就加重了系统负荷，影响系统性能。因此，在SQL Server中，还支持锁升级(lock escalation)。所谓锁升级是指调整锁的粒度，将多个低粒度的锁替换成少数的更高粒度的锁，以此来降低系统负荷。在SQL Server中当一个事务中的锁较多，达到锁升级门限时，系统自动将行级锁和页面锁升级为表级锁。特别值得注意的是，在SQL Server中，锁的升级门限以及锁升级是由系统自动来确定的，不需要用户设置。
网上找的，不知道能不能帮到你。原文的链接是：http://soft.zdnet.com.cn/techupdate/2007/0824/467522.shtml
⑺ 在数据库（MS-SQL)中，UPDATE的用法，UPDATE表示用(NOLOCK)与不用（NOLOCK）的区别
NOLOCK是指在多用户存取数据库时别的用户是否对某一纪录或表加锁,如果加锁了,就不更新,等锁被释放后再更新.避免数据的"脏读".
http://blog.csdn.net/riyao/article/details/8113372
⑻ 如何解决 SQL Server 中的锁升级所致的阻塞问题
防止锁升级的最简单和最安全方法是使短的事务，以便不超过锁升级阈值，会减少昂贵查询的锁定占地面积。有多种方法可以获得这一目标，其中许多将列出：
拆分成几个较小的操作大的批处理操作。例如，假设您运行下面的查询从审核表中，删除几个几十万旧记录并随后发现它导致阻塞其他用户的锁升级：
DELETE FROM LogMessages WHERE LogDate < '2/1/2002'
通过一次删除这些记录几百，可以极大地减少积累每个交易记录，并防止锁升级的锁数。例如：
SET ROWCOUNT 500
delete_more:
DELETE FROM LogMessages WHERE LogDate < '2/1/2002'
IF @@ROWCOUNT > 0 GOTO delete_more
SET ROWCOUNT 0
使查询尽可能高效，从而减少查询的锁的占地面积。大范围的搜索或大量的书签查找可能会增加锁升级 ； 的机会此外，它增加了死锁的可能性，并通常会影响并发性和性能。查找查询后，会导致锁升级，力图寻找销售机会，以创建新的索引，或者若要将列添加到现有索引删除索引和表扫描和索引的效率的最大化。请考虑将查询粘贴到查询分析器的查询窗口以在其上执行自动索引分析。为此，请在查询菜单上，单击在 SQL Server 2000 中，索引优化向导，或单击执行索引分析SQL Server 7.0 中。
这种优化的目标之一是使索引搜索返回尽可能少的行，以书签查找 （最大化的选择性的特定查询的索引） 的成本降到最低。如果 SQL Server 估计书签查找逻辑运算符可能会返回多个行，它可能使用的预取来书签查找。如果 SQL Server 不会使用书签查找预取，必须增加对该查询的一部分可重复的读取查询的一部分的事务隔离级别。这意味着什么可能看起来类似于在读取已提交的隔离级别的 SELECT 语句可能会获取数以千计的键锁 （聚集的索引和上一个非聚集的索引），这可能会导致此类查询超过锁升级阈值。这一点尤其重要，如果您发现已呈报的锁不共享的表锁，其中，但是，通常看不到在默认读取已提交的隔离级别。如果使用预取的书签查找子句导致升级，请考虑将其他列添加到索引查找或下方的书签查找逻辑运算符扫描索引的逻辑运算符出现在查询计划中的非聚集索引。可能会创建覆盖索引 （包括在查询中使用表中的所有列的索引），或至少一个覆盖已选择的列的列表中包括的所有内容如果使用联接条件或 WHERE 子句中的列的索引是不切实际的。
嵌套循环联接也可以使用预取，，这将导致相同的锁定行为。
如果不同的 SPID 当前持有的不兼容表锁，则不会发生锁升级。始终锁升级升级到表级锁，而从不页锁。此外，如果锁定升级尝试失败，因为另一个 SPID 持有的不兼容的选项卡锁，尝试升级该查询不会阻止在等待选项卡锁。相反，它将继续获取锁定在其原始、 更精细的级别 （行、 键或页），定期进行其他升级尝试。因此，防止在某个特定的表上的锁升级的一种方法是获取并与升级的锁类型不兼容的不同连接保持锁定。IX （意向排它） 锁在表级别不会锁定任何行或页，但它仍不兼容已呈报 s （共享的） 或 X （独占） 选项卡上的锁。例如，假设您必须运行的批处理作业修改大量mytable表中的行和已导致阻塞的出现是由于锁升级。如果此作业始终在不到一小时内完成，可能会创建包含以下代码中，事务处理性 SQL 作业和计划新作业启动批处理作业的开始时间前几分钟的时间：
BEGIN TRAN
SELECT * FROM mytable (UPDLOCK, HOLDLOCK) WHERE 1=0
WAITFOR DELAY '1:00:00'
COMMIT TRAN
此查询获取，并一小时，这可以防止在表上的锁升级这段时间内保持在mytable的 IX 锁。这批不会修改任何数据或阻止其他查询 （除非其他查询强制使用 TABLOCK 提示的表锁，或如果管理员已经禁用页或行锁，通过使用sp_indexoption存储过程）。
此外，您可以通过启用跟踪标志 1211年禁用锁升级。但是，此跟踪标记会禁用所有的锁升级的 SQL Server 实例中的全局范围内。锁升级最大化 ； 否则减速的获取和释放锁的数千开销的查询的效率在 SQL Server 中提供非常有用的目的。锁升级还有助于最小化所需的内存，以跟踪的锁。可以将 SQL Server 锁结构中动态分配的内存是有限的的因此如果您禁用锁升级和锁定内存增长足够大、 分配额外的锁包含任何查询可能会失败并出现下面的错误：
错误: 1204，严重性： 19 日状态： 1
这一次，SQL Server 无法获得锁资源。有较少的活动用户时重新运行该语句，或者请求系统管理员检查 SQL Server 锁和内存配置。
注意"1204"错误时，它会停止当前语句的处理，并导致回滚当前事务。回滚本身可能会阻止用户或导致很长的数据库恢复时间，如果您在重新启动 SQL Server 服务。
使用锁定提示 （如 ROWLOCK 只会更改初始锁定计划。锁提示不能防止锁升级。
防止锁升级的前面部分讨论的其他方法是更好的方法比启用跟踪标记。此外，其他方法通常会导致查询性能优于禁用整个实例的锁升级。Microsoft 建议您启用此跟踪标记只是为了缓解严重阻塞引起锁升级，而其他选项，如那些讨论先前在本文中，所调查的。要启用跟踪标志，以便它打开时 SQL Server 启动时，将其添加为服务器启动参数。
添加服务器启动参数，用鼠标右键单击该服务器在 SQL 企业管理器中，单击属性然后单击在常规选项卡上的启动参数，然后添加下面的参数 （严格按照所示）：
-T1211
您必须重新打开 SQL Server 服务为新的启动参数才会生效。如果您在查询分析器中运行下面的查询跟踪标记将立即生效：DBCC TRACEON (1211, -1)
但是，如果您没有添加-T1211启动参数traceon命令的效果时会丢失关闭并重新打开 SQL Server 服务。打开跟踪标志可防止任何将来的锁升级，但它不会反转任何已经发生的活动事务的锁升级。
⑼ mysql直接set锁等待时间需要重启mysql吗
把php.ini中的 ;date.timezone = 修改成 date.timezone = PRC 重启即可 还有 我们一般使用“date -s”命令来修改系统时间。比如将系统时间设定成2005年7月26日的命令如下。 #date -s 03/28/2008 将系统时间设定成下午11点12分0秒的命令如下。 #dat...
⑽ 为什么我们需要在SQL Server里更新锁
首先介绍下当更新锁（Update（U）Lock）获得时，根据它的兼容性锁本身是如何应对的。
一般来说，当执行UPDATE语句时，SQL Server会用到更新锁（Update Lock）。如果查看对应的执行计划，会看到它包含3个部分：
读取数据
计算新值
写入数据
这是其中一个主要原因，为什么关系数据库引擎引入更新锁来实现避免特定的死锁情形。一个更新锁只与一个共享锁兼容，但不与另一个更新或排它锁兼容。因此死锁情形可以被避免，应为2个更新查询计划不可能同时并发运行。在查询的第1阶段，第2个查询会一直等到获得更新锁。System R的一个未公开研究也展示如何避免这类显着的死锁。System R不实用任何更新锁来实现避免死锁。
提升的并发
在第1阶段不获得更新锁，在这个阶段直接获得排它锁也是可见选项。这会克服死锁问题，因为排它锁与另一个排它锁不兼容。但这个方法的问题是并发受限制，因为同时没有其他的SELECT查询可以读取当前有排它锁的数据。因此需要更新锁，因为这个特定锁与传统的共享锁兼容。这样的话其他的SELECT查询可以读取数据，只要这个更新锁还没转化为排它锁。作为副作用，这会提高我们并发运行查询的并发性。
在以前关系学术上，更新锁是所谓的非对称锁（Asymmetric Lock）。在更新锁的上下文里，这个更新锁与共享锁兼容，但反之就不是：共享锁与更新锁不兼容。但SQL Server并不把共享锁作为非对称锁实现。更新锁是个对称（symmetric）的，就是说更新锁和共享锁是彼此双向兼容的。这会提供系统的整体并发，因为在2个锁类型键不会引入阻塞情形。
小结
在今天的文章里你介绍了共享锁，还有为什么需要共享锁在关系数据库，是强烈需要更新锁的，因为不然的就会带来死锁并降低并发。