答案是B，更新锁！解答如下：
共享锁
共享 (S) 锁允许并发事务读取 (SELECT) 一个资源。资源上存在共享 (S) 锁时，任何其它事务都不能修改数据。一旦已经读取数据，便立即释放资源上的共享 (S) 锁，除非将事务隔离级别设置为可重复读或更高级别，或者在事务生存周期内用锁定提示保留共享 (S) 锁。
更新锁
更新 (U) 锁可以防止通常形式的死锁。一般更新模式由一个事务组成，此事务读取记录，获取资源（页或行）的共享 (S) 锁，然后修改行，此操作要求锁转换为排它 (X) 锁。如果两个事务获得了资源上的共享模式锁，然后试图同时更新数据，则一个事务尝试将锁转换为排它 (X) 锁。共享模式到排它锁的转换必须等待一段时间，因为一个事务的排它锁与其它事务的共享模式锁不兼容；发生锁等待。第二个事务试图获取排它 (X) 锁以进行更新。由于两个事务都要转换为排它 (X) 锁，并且每个事务都等待另一个事务释放共享模式锁，因此发生死锁。
若要避免这种潜在的死锁问题，请使用更新 (U) 锁。一次只有一个事务可以获得资源的更新 (U) 锁。如果事务修改资源，则更新 (U) 锁转换为排它 (X) 锁。否则，锁转换为共享锁。
排它锁
排它 (X) 锁可以防止并发事务对资源进行访问。其它事务不能读取或修改排它 (X) 锁锁定的数据。
意向锁
意向锁表示 SQL Server 需要在层次结构中的某些底层资源上获取共享 (S) 锁或排它 (X) 锁。例如，放置在表级的共享意向锁表示事务打算在表中的页或行上放置共享 (S) 锁。在表级设置意向锁可防止另一个事务随后在包含那一页的表上获取排它 (X) 锁。意向锁可以提高性能，因为 SQL Server 仅在表级检查意向锁来确定事务是否可以安全地获取该表上的锁。而无须检查表中的每行或每页上的锁以确定事务是否可以锁定整个表。
意向锁包括意向共享 (IS)、意向排它 (IX) 以及与意向排它共享 (SIX)。
2. 在sql中如何退出while死循环
在sql中如何退出while死循环 和其它的语言没有太大的区别，
牢记循环三要素：循环变量的初始化，循环变量的变更，循环任务
避免死循环是要不要忘记 循环变量的变更
参考代码：
DECLARE
num1 number;
maxstuid number;
age number;
begin
num1 := 1;
WHILE num1 <= 100 LOOP
--获取最大的stuid
select max(stuid) + 1 into maxstuid from whilestu1;
--dbms_output.put_line(maxstuid);
if maxstuid is null then
maxstuid := 1;
--dbms_output.put_line('r');
end if;
age := ROUND(DBMS_RANDOM.VALUE(18, 40), 0);
--插入数据
insert into whilestu1
(stuid, stuName, age)
values
(maxstuid, '学员' || cast(maxstuid as varchar2(50)), age);
commit;
num1 := num1 + 1;
END LOOP;
end;
3. sql如何防止死锁
用事务。transaction
4. 怎么样解决MSSQL产生死锁的问题
一、 什么是死锁
死锁是指两个或两个以上的进程在执行过程中,因争夺资源而造成的一种互相等待的现象,若无外力作用,它们都将无法推进下去.此时称系统处于死锁状态或系统产生了死锁,这些永远在互相等的进程称为死锁进程.
二、 死锁产生的四个必要条件
互斥条件：指进程对所分配到的资源进行排它性使用，即在一段时间内某资源只由一个进程占用。如果此时还有其它进程请求资源，则请求者只能等待，直至占有资源的进程用毕释放
请求和保持条件：指进程已经保持至少一个资源，但又提出了新的资源请求，而该资源已被其它进程占有，此时请求进程阻塞，但又对自己已获得的其它资源保持不放
不剥夺条件：指进程已获得的资源，在未使用完之前，不能被剥夺，只能在使用完时由自己释放
环路等待条件：指在发生死锁时，必然存在一个进程——资源的环形链，即进程集合{P0，P1，P2，···，Pn}中的P0正在等待一个P1占用的资源；P1正在等待P2占用的资源，……，Pn正在等待已被P0占用的资源
这四个条件是死锁的必要条件，只要系统发生死锁，这些条件必然成立，而只要上述条件之一不满足，就不会发生死锁。
三、 如何处理死锁
1) 锁模式
共享锁（S）
由读操作创建的锁，防止在读取数据的过程中，其它事务对数据进行更新；其它事务可以并发读取数据。共享锁可以加在表、页、索引键或者数据行上。在SQL SERVER默认隔离级别下数据读取完毕后就会释放共享锁，但可以通过锁提示或设置更高的事务隔离级别改变共享锁的释放时间。
2.独占锁(X)
对资源独占的锁，一个进程独占地锁定了请求的数据源，那么别的进程无法在此数据源上获得任何类型的锁。独占锁一致持有到事务结束。
3.更新锁(U)
更新锁实际上并不是一种独立的锁，而是共享锁与独占锁的混合。当SQL SERVER执行数据修改操作却首先需要搜索表以找到需要修改的资源时，会获得更新锁。
更新锁与共享锁兼容，但只有一个进程可以获取当前数据源上的更新锁，
其它进程无法获取该资源的更新锁或独占锁，更新锁的作用就好像一个序列化阀门（serialization gate），将后续申请独占锁的请求压入队列中。持有更新锁的进程能够将其转换成该资源上的独占锁。更新锁不足以用于更新数据—实际的数据修改仍需要用到独占锁。对于独占锁的序列化访问可以避免转换死锁的发生，更新锁会保留到事务结束或者当它们转换成独占锁时为止。
4. 意向锁(IX,IU,IS)
意向锁并不是独立的锁定模式，而是一种指出哪些资源已经被锁定的机制。
如果一个表页上存在独占锁，那么另一个进程就无法获得该表上的共享表锁，这种层次关系是用意向锁来实现的。进程要获得独占页锁、更新页锁或意向独占页锁，首先必须获得该表上的意向独占锁。同理，进程要获得共享行锁，必须首先获得该表的意向共享锁，以防止别的进程获得独占表锁。
5. 特殊锁模式(Sch_s,Sch_m,BU)
SQL SERVER提供3种额外的锁模式：架构稳定锁、架构修改锁、大容量更新锁。
6.转换锁(SIX,SIU,UIX)
转换锁不会由SQL SERVER 直接请求，而是从一种模式转换到另一种模式所造成的。SQL SERVER 2008支持3种类型的转换锁：SIX、SIU、UIX.其中最常见的是SIX锁，如果事务持有一个资源上的共享锁（S），然后又需要一个IX锁，此时就会出现SIX。
7.键范围锁
键范围锁是在可序列化隔离级别中锁定一定范围内数据的锁。保证在查询数据的键范围内不允许插入数据。
http://www.cnblogs.com/qiaokai/p/5344252.html
5. SQL 进程死锁
首先，需要把你的AutoCommit=TRUE，然后，这是一个编程习惯问题，在pb中，对于数据窗口的操作，首先设置数据窗口的提交方式，我一直
采用 key columns,use
update，然后记得在每次连接完成后，记得及时释放，譬如，在retrieve完成后，记得及时利用resetupdate()清除数据状态，然后，
再每次数据库更新，也就是update()后，记得利用
ll_num1=.update()
if ll_num=1 then
commit;
dw_free.resetupdate( )
else
rollback;
messagebox("提示!","数据保存失败! ")
end if
以上说法我不赞同：
1、首先AutoCommit=TRUE，以后执行delete，update，insert语句都相当执行了commit，如果是把几个SQL语句当作是一个完整的事务，要不整
体成功提交，要不rollback，这就写就不会得到正确的结果。
2、其次key columns,use update，要具体情况具体使用，这种形式的并发性最差，适合对数据的并发性要求不高的场合。
3、再次程序的死锁原因是多方面的，上述两个方面只是其中的原因罢了，具体情况具体分析，例如数据尽快提交、建立合理的索引、合理的SQ
L语句、避免交叉事务、对于数据量庞大的表，应及时转移到历史库，我想可以很大程度上避免死锁。
以上愚见，欢迎拍砖。
在MSSQL控制台中，管理－当前活动－锁／进程ID看看是那几个进程在死锁，然后在进程信息中将这些死锁的进程杀死／
对查询进行优化
也建议检查：外键建立索引，如果上索引，再调试下网络
对外键建索引可以缓解这个问题。
如在商品字典和销售明细表中，销售明细表中商品编号是外键，如果在销售明细表的商品编号上没有索引，update商品字典会造成销售明细表
整表锁表。
解决Sybase数据库死锁的方法
人民银行吉林市中心支行科技处 刘志明
在联机事务处理(OLTP)的数据库应用系统中，多用户、多任务的并发性是系统最重要的技术指标之一。为了提高并发性，目前大部分RDBMS都采
用加锁技术。然而由于现实环境的复杂性，使用加锁技术又不可避免地产生了死锁问题。因此如何合理有效地使用加锁技术，最小化死锁是开
发联机事务处理系统的关键。
死锁产生的原因
在联机事务处理系统中，造成死机主要有两方面原因。一方面，由于多用户、多任务的并发性和事务的完整性要求，当多个事务处理对多个资
源同时访问时，若双方已锁定一部分资源但也都需要对方已锁定的资源时，无法在有限的时间内完全获得所需的资源，就会处于无限的等待状
态，从而造成其对资源需求的死锁。
另一方面，数据库本身加锁机制的实现方法不同，各数据库系统也会产生其特殊的死锁情况。如在Sybase SQL Server 11中，最小锁为2K一页
的加锁方法，而非行级锁。如果某张表的记录数少且记录的长度较短(即记录密度高，如应用系统中的系统配置表或系统参数表就属于此类表)
，被访问的频率高，就容易在该页上产生死锁。
几种死锁情况及解决方法
清算应用系统中，容易发生死锁的几种情况如下:
● 不同的存储过程、触发器、动态SQL语句段按照不同的顺序同时访问多张表;
● 在交换期间添加记录频繁的表，但在该表上使用了非群集索引(non-clustered);
● 表中的记录少，且单条记录较短，被访问的频率较高；
● 整张表被访问的频率高(如代码对照表的查询等)。
以上死锁情况的对应处理方法如下：
● 在系统实现时应规定所有存储过程、触发器、动态SQL语句段中，对多张表的操作总是使用同一顺序。如：有两个存储过程proc1、proc2，
都需要访问三张表zltab、z2tab和z3tab，如果proc1按照zltab、z2tab和z3tab的顺序进行访问，那么，proc2也应该按照以上顺序访问这三张
表。
● 对在交换期间添加记录频繁的表，使用群集索引(clustered)，以减少多个用户添加记录到该表的最后一页上，在表尾产生热点，造成死锁
。这类表多为往来账的流水表，其特点是在交换期间需要在表尾追加大量的记录，并且对已添加的记录不做或较少做删除操作。
● 对单张表中记录数不太多，且在交换期间select或updata较频繁的表可使用设置每页最大行的办法，减少数据在表中存放的密度，模拟行级
锁，减少在该表上死锁情况的发生。这类表多为信息繁杂且记录条数少的表。
如：系统配置表或系统参数表。在定义该表时添加如下语句：
with max_rows_per_page=1
● 在存储过程、触发器、动态SQL语句段中，若对某些整张表select操作较频繁，则可能在该表上与其他访问该表的用户产生死锁。对于检查
账号是否存在，但被检查的字段在检查期间不会被更新等非关键语句，可以采用在select命令中使用at isolation read uncommitted子句的方
法解决。该方法实际上降低了select语句对整张表的锁级别，提高了其他用户对该表操作的并发性。在系统高负荷运行时，该方法的效果尤为
显着。
例如：
select*from titles at isolation read uncommitted
● 对流水号一类的顺序数生成器字段，可以先执行updata流水号字段+1，然后再执行select获取流水号的方法进行操作。
小结
笔者对同城清算系统进行压力测试时，分别对采用上述优化方法和不采用优化方法的两套系统进行测试。在其他条件相同的情况下，相同业务
笔数、相同时间内，死锁发生的情况如下：
采用优化方法的系统: 0次/万笔业务;
不采用优化方法的系统：50～200次/万笔业务。
所以，使用上述优化方法后，特别是在系统高负荷运行时效果尤为显着。总之，在设计、开发数据库应用系统，尤其是OLTP系统时，应该根据
应用系统的具体情况，依据上述原则对系统分别优化，为开发一套高效、可靠的应用系统打下良好的基础。
经验：
1：前台问题：检视代码查看事物是否被提交或回滚。
2：后台问题：有时候由于处理的问题复杂度高。数据库日志空间已满或不够
导致事物未能提交。UNIX下的SYBAE就是典型的一例。解决办法各数据库厂商有更详细的说明。
虽然我从9转到10遇到了好多问题，也浪费了好几天的时间，但到了现在，我真觉得10比9好。
10没有了MSSQL专用接口，用的是OLEDB接口，用这个接口一定要注意一个问题是表死锁的事!
网上讲的连接方式都是天下一大抄。
用OLEDB要加上 SQLCA.Lock = "RC"，
不然连查询也会死锁。
另个一个就是10写的软件不再乱码了，我在繁体写的软件在简体下运行不乱码，反之也可以。
第三就是编译速度明显快很多。
第四就是编译的时候有了XP样式皮肤，感觉漂亮多了。
编程要是要养成好习惯，在sql语句insert和update之后，要及时commit，数据窗口update()后也要及时commit;
阻塞是因为多个进程对同一一个资源的访问冲突，当一个进程排它访问一个资源时（从进入事务到事务结束为止），当有其他进程需要访问同
样的资源时，即造成阻塞（根据锁的级别和粒度设置）；
在实际应用中阻塞可能因为事务没有提交或者网络速度太慢或者大容量的数据查询等都可能会造成阻塞。
阻塞可以通过sp_who 系统存储过程进行查看，执行sp_who 后查看所有blk不等于
0的进程ID（SPID），直到找到SPID在blk列出现，但当前spid 的blk列 =0 即它就是阻塞的源头。
最简单的办法可用 kill spid(源头进程的SPID值)，同时结合sp_lock过程可查看到当前进程的加锁情况（如锁的类型被锁的对象）
最后最重要的是要根据 在查询到源头后，使用 DBCC INPUTBUFFER (spid)查看最后一次提交的内容，即可找到因为事务没有提交造成的阻塞（
一般不能使用 AutoCommit=True，因为大部分MIS程序需要使用批提交，来保证数据的完成性）
http://www.51onnet.com/bbs/forumdisplay.php?f=6
你可能平时编程时没有注意。在 SQLCA（Transaction）默认情况下 AutoCommit = false（不自动提交）。在同一事务中，如果不提交事务，
可以SELECT、Retrieve，但其它事务（其它计算机的应用程序连接数据库的事务）就不能。所以导致死锁，而在单机开发环境看不出来。
你需要在所有的 UPDATE、DELETE 的SQL语句后面，或者数据窗口的Update函数调用之后执行 COMMIT 或 ROLLBACK
死锁可能存在的原因及解决办法
一次偶然的机会在论坛上看到一个关于死锁（其实是阻塞）的帖子，于是把自己的一个小东东拿出来和大家分享，想不到很多人都遇到过这个
问题。
其实解锁并不是根本的解决办法，感觉我自己有点误导大家了，于是有了下面的内容，希望大家能根据自己的应用找出根源，而不是解锁：
阻塞可能存在的原因及解决方法：
1、事务未提交
这是造成阻塞最常见的原因，因为PB默认是自动启动事务的，如果你执行了 update,delete ,insert 语句，不执行Commit 则会出现阻塞（
不建议采用自动提交事务的方式，原因在上一帖中交代过），解决的办法很简单，查找到所有的修改数据命令(U、I、D)查看是否正常提交，找
到后加入Commit即可；
2、SQL SERVER 没有正常安装SP3
对于代码正常的用户，仍然出现阻塞，则需要检查你机器的补丁，特别是WIN2003的机器不安装补丁，1433都不能监听；如果没有安装补丁
即可（我原来就是被这种情况害过）
3、当然可能你会告诉我，代码也没有问题，补丁也装了，仍然出现可能就需要查看你的机器的CPU和内存的使用率（运行taskmgr），SQL
SERVER 的机器峰值状态可能出现阻塞，解决的办法就是出钱：升级服务器；
4、复杂的查询或者大容量查询，比如在查询中使用多个表的联合查询，或者使用 in ,not in 等语句，是非常耗时的，这种解决的办法稍微复
杂点，需要根据你的应用修改SQL 语句，优化SQL 效率，关于SQL 优化是另外一个复杂的话题，本人也学习中...
能想起的好象就这些了，可能不是很完善，希望有人能补充！
你可能平时编程时没有注意。在 SQLCA（Transaction）默认情况下 AutoCommit = false（不自动提交）。在同一事务中，如果不提交事务，
可以SELECT、Retrieve，但其它事务（其它计算机的应用程序连接数据库的事务）就不能。所以导致死锁，而在单机开发环境看不出来。
你需要在所有的 UPDATE、DELETE 的SQL语句后面，或者数据窗口的Update函数调用之后执行 COMMIT 或 ROLLBACK
补充一点,除了在执行了Update,Delete,Insert需要及时Commit外,在SQL Server中由于使用一个Tempdb的数据库,这个数据库是对所有用户共享
的,当使用了统计类型的SQL函数如:sum,count等,SQL Server会自动使用Tempdb进行暂存统计数据,这样很容易造成Tempdb被锁住,所以在读取了
一个很复杂Store Procere或创建过临时表后应进行commit,以便释放Tempdb资源,在retrieved事件中加commit是一个解决办法,特别是在读取
报表后更应加,一般报表的Store Procere都比较复杂,在程序中内嵌了SQL光标来读取数据后也要加commit,我增经试过被锁住,找了很久才知
6. 在sql中运行的时候一直执行查询 不出结果是怎么回事
1. 网络不行
2. 表数据过多，条件限制太少
3. 多表查询时，表之间的连接条件缺少
7. sql update 语句中怎么设置那时间不定死
update table set time =getdate()
8. 在sql中如何退出while死循环
1.【格式】
WHILE Boolean_expression
{sql语句|语句块}
[BREAK]
{sql语句|语句块}
[CONTINUE]
2.【示例】
DECLARE @s int,@i int
SET @i = 0
SET @s = 0
WHILE @i<=100
BEGIN
SET @s = @s+@i
SET @i = @i+1
END
PRINT ‘1+2+…+100=’+CAST(@s AS char(25))
9. 如何查看SQL死锁
其实所有的死锁最深层的原因就是一个:资源竞争
表现一:
一个用户A 访问表A(锁住了表A),然后又访问表B
另一个用户B 访问表B(锁住了表B),然后企图访问表A
这时用户A由于用户B已经锁住表B，它必须等待用户B释放表B,才能继续，好了他老人家就只好老老实实在这等了
同样用户B要等用户A释放表A才能继续这就死锁了
解决方法：
这种死锁是由于你的程序的BUG产生的，除了调整你的程序的逻辑别无他法
仔细分析你程序的逻辑，
1：尽量避免同时锁定两个资源
2: 必须同时锁定两个资源时，要保证在任何时刻都应该按照相同的顺序来锁定资源.
表现二:
用户A读一条纪录，然后修改该条纪录
这是用户B修改该条纪录
这里用户A的事务里锁的性质由共享锁企图上升到独占锁(for update),而用户B里的独占锁由于A有共享锁存在所以必须等A释
放掉共享锁，而A由于B的独占锁而无法上升的独占锁也就不可能释放共享锁，于是出现了死锁。
这种死锁比较隐蔽，但其实在稍大点的项目中经常发生。
解决方法:
让用户A的事务（即先读后写类型的操作),在select 时就是用Update lock
语法如下：
select * from table1 with(updlock) where ....