Sybase封锁原理

       昨天在操作Sybase IQ12.7时意外操作造成了数据库表锁定，不能删除被锁定表数据也不能往其中写入数据。由于着急往该表抽入数据，因此立马着手解决该表的解锁问题。

     无奈此前没有接触过Sybase IQ12.7这套数据库产品，加之当时已属于下班时间无法求助于支持人员支持，因此只有借助搜索引擎强大的搜索能力，通过搜索结果了解到死锁的原理如下：

    Sybase封锁原理

　　数据共享与数据一致性是一对不可调和的矛盾，为了达到数据共享与数据一致，必须进行并发控制。并发控制的任务就是为了避免共享冲突而引起的数据不一致。Sybase SQL Server并发控制的方法是加锁机制（LOCKING）.

锁的类型 　　可申请的锁
已有的锁 S U X
S ∨ ∨ ×
U ∨ × ×
X × × ×
　　Sybase SQL Server有三种封锁类型：排它锁（exclusive lock,简称X锁）；共享锁（share lock,简称S锁）；更新锁（update lock,简称U锁）。这三种锁的相容矩阵表如下：
　　×:表示不兼容。∨：表示兼容。　　Sybase SQL Server是自动决定加锁类型的。一般来说，读（SELECT）操作使用S锁，写（UPDATE,INSERT和delete）操作使用X锁。U锁是建立在页级上的，它在一个更新操作开始时获得，当要修改这些页时，U锁会升级为X锁。

锁的力度
　　SQL Server有两级锁：页锁和表锁。通常页锁比表锁的限制更少（或更小）。页锁对本页的所有行进行锁定，而表锁则锁定整个表。为了减小用户间的数据争用和改进并发性，SQL Server试图尽可能地使用页锁。
　　当SQL Server决定一个语句将访问整个表或表的大多数页时，它用表锁来提供更有效的锁定。锁定策略直接受查询方案约束，如果update或delete语句没有可用的索引，它就执行表扫描或请求一个表锁定。如果update或delete语句使用了索引，它就通过请求页锁来开始，如果影响到大多数行，它就要请求表锁。一旦一个语句积累的页锁超过锁提升阈值，SQL Server就设法给该对象分配一个表锁。如果成功了，页锁就不再必要了，因此被释放。表锁也在页层提供避免锁冲突的方法。对于有些命令SQL Server自动使用表锁。

锁的状态
　　SQL SERVER加锁有三种状态：
　　1）意向锁（intend）—是一种表级锁，它表示在一个数据页上获得一个S或X锁的意向。意向锁可以防止其他事务在该数据页的表上获得排它锁。
　　2）阻塞（blocking,简记blk）—它表明目前加锁进程的状态，带有blk后缀的锁说明该进程目前正阻塞另一个需要获得锁的进程，只有这一进程完成，其他进程才可以进行。
　　3）需求锁（demand）—表示此时该进程企图得到一个排它锁。它可以防止在这一表或页上加过多的S锁，她表示某一事务是下一个去锁定该表和该页的事务。
　　需求锁是一个内部过程，因此用sp_lock是无法看见的。

死锁DEADLOCK
　　简单地说，有两个用户进程，每个进程都在一个单独的页或表上有一个锁，而且每个进程都想在对方进程的页或表上请求不相容锁时就会发生“死锁”。在这种情况下，第一个进程在等待另一进程释放锁，但另一进程要等到第一个进程的对象释放时才会释放自己的锁。
　　SQL Server检查是否死锁，并终止事务中CPU时间积累最小的用户（即最后进入的用户）。SQL Server回滚该用户的事务，并用消息号1205通知有此死锁行为的应用程序，然后允许其他用户进程继续进行。
　　在多用户情形下，每个用户的应用程序都应检查每个修改数据的事务是否有1205号消息，以此确定是否有可能死锁。消息号1025表示该用户的事务因死锁而终止并被回滚。应用程序必须重新开始这个事务处理。

了解到锁的原理后，按照搜索提供的SP_LOCK,SP_WHO等系统过程准备查找造成锁定的原因，但一直为成功，这个问题困惑了我很久，最后通过查阅IQ相关帮助文档，得知应采用如下方式（目标数据库为Sybase IQ12,7)

   要解除IQ锁定，可以用sp_iqlocks查看当前库中有那些锁定，并找到想要解锁的那个被锁定的链接的connection ID,然后用drop connection +链接号去杀死链接
此外还可以用sp_iqwho可以查看谁在使用IQ