db2事务锁机制.docx
《db2事务锁机制.docx》由会员分享，可在线阅读，更多相关《db2事务锁机制.docx（16页珍藏版）》请在冰豆网上搜索。
db2事务锁机制
使用单用户数据库时，每个事务都是顺序执行的，而不必应付与其它事务的冲突。
但是，在多用户数据库环境下，多个事务可以同步执行，并且每个事务都有可能与其它正在运行的事务发生冲突。
在多用户环境下，如果不将事务彼此隔离开来，就会发生四种现象：
（1）丢失更新：
这种事件发生在两个事务读取和尝试更新同一数据时，其中一个更新会丢失。
例如：
事务1和事务2读取同一行数据，并都根据所读取的数据计算出该行的新值。
如果事务1用其新值更新该行以后，事务2又更新了同一行，则事务1所执行的更新操作就丢失了。
由于设计的方法，DB2通用数据库不允许发生此类现象。
（2）脏读：
当事务读取尚未提交的数据时，就会发生这种事件。
例如：
事务1更改了一行数据，而事务2在事务1提交更改之前读取了已更改的行。
如果事务1回滚该更改，则事务2就会读取被认为是不曾存在的数据。
（3）不可重复的读：
当一个事务两次读取同一行数据，但每次获得不同的数据值时，就会发生这种事件。
例如：
事务1读取了一行数据，而事务2在更改或删除该行后提交了更改。
当事务1尝试再次读取该行时，它会检索到不同的数据值（如果该行已经被更新的话），或发现该行不复存在了（如果该行被删除的话）。
（4）幻像：
当最初没有看到某个与搜索条件匹配的数据行，而在稍后的读操作中又看到该行时，就会发生这种事件。
例如：
事务1读取满足某个搜索条件的一组数据行，而事务2插入了与事务1搜索条件匹配的新行。
如果事务1再次执行产生原先行集的查询，则会检索到不同的行集。
锁
所谓锁就是事务T在对某个数据对象——例如表、记录等——操作之前，先向系统发出请求，对其加锁，加锁后事务T就对该数据对象有一定的控制，在事务T释放它的锁之前，其它事务不能更新此数据对象。
基本的封锁类型有两种：
排他锁（ExclusiveLocks，简称X锁）和共享锁（ShareLocks，简称S锁）。
排他锁又称为写锁，若事务T对数据对象A加上X锁，则只允许T读取和修改A，其它任何事务都不能再对A加任何类型的锁，直到T释放A上的锁。
这就保证了其它事务在T释放A上的锁之前不能再读取和修改A。
共享锁又称为读锁，若事务T对数据对象A加上S锁，则事务T可以读A但不能修改A，其它事务只能再对A加S锁，而不能加X锁，直到T释放A上的S锁。
这就保证了其它事务可以读A，但在T释放A上的S锁之前不能对A做任何修改。
锁的兼容性
[code]
X S －
X N N Y
S N Y Y
－ Y Y Y
[/code]
封锁协议
一级封锁协议：
事务T在修改数据R之前必须先对其加X锁，直到事务结束才释放。
一级封锁协议可以防止丢失更新，并保证事务T是可恢复的。
但是不能防止脏读、不可重复的读及幻象。
二级封锁协议：
一级封锁协议加上事务T在读取数据R之前必须先对其加S锁，读完后立即释放S锁。
二级封锁协议可以防止丢失更新、脏读，但是不能防止不可重复的读和幻象。
三级封锁协议：
一级封锁协议加上事务T在读取数据R之前必须先对其加S锁，直到事务结束才释放S锁。
三级封锁协议可以防止丢失更新、脏读、不可重复的读和幻象。
隔离级别
维护数据库一致性和数据完整性，但又允许多个应用程序同时访问同一数据，这样的特性称为并发性。
DB2通用数据库尝试用来强制执行并发性的方法之一是通过使用隔离级别，它决定在第一个事务访问数据时，如何对其它事务锁定或隔离该事务所使用的数据。
DB2通用数据库使用下列隔离级别来强制执行并发性：
（1）可重复的读（RepeatableRead）
（2）读稳定性（ReadStability）
（3）游标稳定性（CursorStability）
（4）未提交的读（UncommittedRead）
“可重复的读”隔离级别
当使用可重复的读隔离级别时，在单个事务执行期间锁定该事务引用的所有行。
使用这种隔离级别时，同一事务多次发出的同一个SELECT语句将始终产生同一结果；丢失更新、脏读、不可重复的读、幻像都不会发生。
该隔离级别对应于三级封锁协议。
使用可重复的读隔离级别的事务可以多次检索同一行集，并可以对它们执行任意次操作，直到由提交或回滚操作终止事务；不允许其它事务执行插入、更新或删除操作，因为这些操作会在隔离事务存在期间影响正在被使用的行集。
为了确保在“可重复的读”隔离级别下运行的事务所访问的数据不会受其它事务的负面影响，所以锁定了该隔离事务所引用的每个行—而不是仅锁定被实际检索和／或修改的那些行。
因此，如果一个事务扫描了1000行但只检索10行，则所扫描的1000行（而不仅是被检索的10行）都会被锁定。
那么在现实环境中这个隔离级别是如何工作的呢？
假定您拥有一家大型旅馆，并有一个网站，该网站按“先到先服务”的原则接受客户的房间预订。
如果您的旅馆预订应用程序是在“可重复的读”隔离级别下运行的，当客户检索某个日期段内的所有可用房间列表时，您将无法更改那些房间在指定日期范围内的费用，而其他客户也将无法进行或取消将会更改该列表的预订，直到生成该列表的事务终止为止。
（对于第一个客户的查询所指定范围之外的任何房间，您都可以更改房价，其他客户也都可以进行或取消房间预订。
）
“读稳定性”隔离级别
当使用读稳定性隔离级别时，在单个事务执行期间，会锁定该事务所检索的所有行。
当使用这种隔离级别时，直到隔离事务终止之前，其它事务不能更改隔离事务读取的所有行。
此外，其它事务对其它行所作的更改，在提交之前对于运行在“读稳定性”隔离级别下的事务而言是不可见的。
因此，当使用“读稳定性”隔离级别时，在同一事务中多次发出SELECT语句可能会产生不同的结果。
丢失更新、脏读和不可重复的读都不会发生；但是，有可能出现幻像。
使用“可重复的读”隔离级别时，隔离事务引用的每一行都被锁定；但是，在“读稳定性”隔离级别下，只锁定隔离事务实际检索和／或修改的行。
因此，如果一个事务扫描了1000行但只检索10行，则只有被检索到的10行（而不是所扫描的1000行）被锁定。
那么，这种隔离级别会如何改变旅馆预订应用程序的工作方式呢？
现在，当一个客户检索某个日期段内的所有可用房间列表时，您可以更改旅馆中任何房间的房价，而其他客户也可以取消在第一个客户的查询所指定的日期段内所保留房间的预订。
因此，如果在终止提交查询的事务之前再次生成列表，则产生的新列表中有可能包含新的房价或第一次产生列表时不可用的房间。
“游标稳定性”隔离级别
当使用游标稳定性隔离级别时，只要隔离事务所用的游标定位在某一行上，就会锁定该游标所引用的这一行。
所获取的锁一直有效，直到游标重定位（通常通过调用FETCH语句）或隔离事务终止为止。
因此，当使用这种隔离级别时，在同一事务中多次发出SELECT语句可能会产生不同的结果。
丢失更新和脏读不会发生；但有可能出现不可重复的读和幻像。
该隔离级别对应于二级封锁协议。
当使用“游标稳定性”隔离级别的事务通过可更新游标从表中检索行时，在游标定位在该行上时，其它事务不能更新或删除该行。
但是，如果被锁定的行本身不是用索引访问的，那么其它事务可以将新的行添加到表，并对位于被锁定行前后的行进行更新和／或删除操作。
此外，如果隔离事务修改了它检索到的任何行，那么在隔离事务终止之前，即使在游标不再位于这个被修改的行，其它事务不能更新或删除该行。
其它事务在其它行上进行的更改，在提交之前对于使用“游标稳定性”隔离级别的事务是不可见的。
缺省情况下，大多数事务都使用“游标稳定性”隔离级别。
这种隔离级别对旅馆预订应用程序有什么影响呢？
现在，当一个客户检索某个日期段内的所有可用房间列表，然后查看关于所产生的列表上每个房间的信息时（每次查看一个房间），您可以更改旅馆中任何房间的房价，而其他客户可以对任何日期段的任何房间进行或取消预订；唯一的例外是第一个客户当前正在查看的房间。
当第一个客户查看列表中另一个房间的信息时，对于这个新房间也是一样；您现在可以更改第一个客户刚才查看的房间的房价，其他客户也可以预订该房间，但不能对第一个客户当前正在查看的房间进行这些操作。
“未提交的读”隔离级别
在使用未提交的读隔离级别的情况中，当单个事务检索行时，仅当另一个事务试图删除或更改被检索的行所在的表时，才会在单个事务期间锁定这些行。
因为在使用这种隔离级别时，行通常保持未锁定状态，所以丢失更新、脏读、不可重复的读和幻像都可能会发生。
在大多数情况下，其它事务对行所作的更改，在提交或回滚之前对于使用“未提交的读”隔离级别的事务是可见的。
但是，此类事务不能看见或访问其它事务所创建的表、视图或索引，直到那些事务被提交为止。
类似地，如果其它事务删除了现有的表、视图或索引，使用“未提交的读”隔离级别的事务仅当进行删除操作的事务终止时才能了解这一情况。
这种行为有一个例外：
当运行在“未提交的读”隔离级别下的事务使用可更新游标时，该事务的行为和在“游标稳定性”隔离级别下运行一样，并应用“游标稳定性”隔离级别的约束。
“未提交的读”隔离级别通常用于那些访问只读表的事务和／或某些执行SELECT语句的事务，这些语句对其它事务的未提交数据没有负面效果。
那么这种隔离级别对旅馆预订应用程序有什么影响呢？
现在，当一个客户检索某个日期段内的所有可用房间列表时，您可以更改旅馆中任何房间的房价，而其它客户也可以对任何日期段内的任何房间进行或取消预订。
此外，如果其它客户取消了预订，即使他们还没有终止其事务并将那些取消提交到数据库，所生成的列表就可以包含这些取消预订的房间了。
选择适当的隔离级别
选择用于事务的适当隔离级别是非常重要的。
隔离级别不仅影响数据库如何很好地支持并发性；而且影响包含该事务的应用程序的整体性能。
这是因为获取和释放锁所需的资源因隔离级别而异。
通常，使用的隔离级别越严格，对并发性提供的支持就越少，而整体性能可能会越低，因为要获取并占有更多的资源。
但是，当您确定将要使用的最佳隔离级别时，应该通过确定哪些现象可接受而哪些现象不可接受来进行决策。
下列推断可以用来帮助您确定在特定环境中使用哪种隔离级别：
· 如果您正在只读数据库上执行查询，或者正在执行查询而不考虑是否有未提交的数据值返回，则使用“未提交的读”隔离级别。
（需要是只读事务—不需要较高的数据稳定性。
）
· 如果您希望在不看见未提交数据值的情况下获得最大的并发性，则使用“游标稳定性”隔离级别。
（需要是读／写事务—不需要较高的数据稳定性。
）
· 如果您希望获得并发性，并希望限定的行在单个事务执行期间保持稳定，则使用“读稳定性”隔离级别。
（需要是只读或读／写事务—需要较高的数据稳定性。
）
· 如果您正在执行查询，并且不希望看到对产生的结果数据集进行更改，则使用“可重复的读”隔离级别。
（需要是只读事务—需要极高的数据稳定性。
）
多粒度封锁
首先定义多粒度树。
多粒度树的根节点是整个数据库，表示最大的数据粒度，叶节点表示最小的数据粒度，例如：
多粒度封锁协议允许多粒度树中的每个节点被独立地加锁。
对一个节点加锁意味着这个节点的所有后裔节点也被加以同样类型的锁。
在多粒度锁中一个数据对象可能以两种方式封锁，显式封锁和隐式封锁。
显式封锁是应事务要求直接加到数据对象上的锁；隐式封锁是该数据对象没有独立加锁，而是由于其上级节点加锁而使该数据对象加上了锁。
多粒度封锁方法中，显式封锁和隐式封锁的效果是一样的，因此系统检查封锁冲突时不仅检查显式封锁还要检查隐式封锁。
一般地，对某个数据对象加锁，系统要检查该数据对象上有无显式封锁与之冲突；还要检查其所有上级节点，看本事务的显式封锁是否与该数据对象上的隐式封锁（即由于上级节点已加的封锁造成的）冲突；还要检查其所有下级节点，看上面的显式封锁是否与本事务的隐式封锁（将加到下级节点的封锁）冲突。
由于这种方法效率很低，故引进一种新型锁，称为意向锁。
意向锁
给一个节点加意向锁，意味着该节点下层节点正在被加锁；对任一节点加锁时，必须先对它的上层节点加意向锁。
于是事务T要对表R1加X锁时，系统只要检查根节点数据库和表R1是否已加了不相容的锁，而不再需要搜索和检查R1中的每一个记录是否加了X锁。
下面介绍三种常用的意向锁：
意向共享锁（IntentShareLock，简称IS锁）；意向排他锁（IntentExclusiveLock，IX）；共享意向排他锁（ShareIntentExclusiveLock，SIX）
1. IS锁
如果对一个数据对象加IS锁，表示它的后裔节点拟加S锁。
例如，要对某个记录加S锁，则要首先对表和数据库加IS锁。
2. IX锁
如果对一个数据对象加IX锁，表示它的后裔节点拟加X锁。
例如，要对某个记录加X锁，则要首先对表和数据库加IX锁。
3. SIX锁
如果对一个数据对象加SIX锁，表示对它加S锁，再加IX锁，即SIX=S+IX。
例如，对某个表加SIX锁，则表示该事务要读整个表（所以要加S锁），同时会更新个别记录（所以要对该表加IX锁）。
兼容性
[code]
S X IS IX SIX －
S Y N Y N N Y
X N Y Y N N Y
IS Y N Y Y Y Y
IX N N Y Y N Y
SIX N N Y N N Y
－ Y Y Y Y Y Y[/code]
锁状态：
锁的类型
锁状态确定了对锁的所有者允许的访问类型，以及对锁定数据资源的并发用户许可的访问类型。
下面的列表说明了可用的锁状态，按照递增控制排序：
锁状态（模式）：
意向无（IntentNone，IN）
适用对象：
表空间和表
描述：
锁的拥有者可以读取锁定表中的数据（包括未提交数据），但不能更改这些数据。
在这种模式中，锁的拥有者不获取行级别的锁；因此，其它并发应用程序可以读取和更改表中的数据。
锁状态（模式）：
意向共享（IntentShare，IS）
适用对象：
表空间和表
描述：
锁的拥有者可以读取锁定表中的数据，但不能更改这些数据。
同样，因为锁的拥有者不获取行级别锁；所以，其它并发的应用程序仍可以读取和更改表中的数据。
（当事务拥有表上的意向共享锁时，就在它所读取的每个行上进行共享锁定。
）当事务不传达更新表中行的意图时，就获取这种锁。
锁状态（模式）：
下一键共享（NextKeyShare，NS）
适用对象：
行
描述：
锁拥有者和所有并发的事务都可以读（但不能更改）锁定行中的数据。
这种锁用来在使用“读稳定性”或“游标稳定性”事务隔离级别读取的数据上代替共享锁。
锁状态（模式）：
共享（S）
适用对象：
表和行
描述：
锁拥有者和任何其它并发的事务都可以读（但不能更改）锁定的表或行中的数据。
只要表不是使用共享锁锁定的，那么该表中的单个行可以使用共享锁锁定。
但是，如果表是用共享锁定的，则锁拥有者不能在该表中获取行级别的共享锁。
如果表或行是用共享锁锁定的，则其它并发事务可以读取数据，但不能对它进行更改。
锁状态（模式）：
意向互斥（IntentExclusive，IX）
适用对象：
表空间和表
描述：
锁拥有者和任何其它并发的应用程序都可以读取和更改被锁定表中的数据。
当锁拥有者从表读取数据时，它在所读取的每一行上获取一个共享锁，而在它更新的每一行上获取更新和互斥锁。
其它并发的应用程序可以读取和更新锁定的表。
当事务传达更新表中行的意图时，就获取这种锁。
（SELECTFORUPDATE、UPDATE...WHERE和INSERT语句传达更新的意图。
）
锁状态（模式）：
带意向互斥的共享（ShareWithIntentExclusive，SIX）
适用对象：
表
描述：
锁拥有者可以读取和更改被锁定表中的数据。
锁拥有者在它更新的行上获取互斥锁，但不获取它读取的行上的锁；因此，其它并发的应用程序可以读取但不能更新被锁定表中的数据。
锁状态（模式）：
更新（Update，U）
适用对象：
表和行
描述：
锁的拥有者可以更新被锁定表中的数据，并且锁的拥有者在它所更新的任何行上自动获得互斥锁。
其它并发的应用程序可以但不能更新被锁定表中的数据。
锁状态（模式）：
下一键互斥（NextKeyExclusive，NX）
适用对象：
行
描述：
锁的拥有者可以读取但不能更新被锁定的行。
当在表的索引中插入或删除行时，表中的下一行上将获得这种锁。
锁状态（模式）：
下一键弱互斥（NextKeyWeakExclusive，NW）
适用对象：
行
描述：
锁的拥有者可以读取但不能更新被锁定的行。
当向非目录表的索引插入行时，表中下一行上就获得这种锁。
锁状态（模式）：
互斥（Exclusive，X）
适用对象：
表和行
描述：
锁的拥有者可以读取和更改被锁定的表或行中的数据。
如果获取了互斥锁，则只允许使用“未提交的读”隔离级别的应用程序访问被锁定的表或行（多行）。
对于用INSERT、UPDATE和／或DELETE语句操作的数据资源，将获取互斥锁。
锁状态（模式）：
弱互斥（WeakExclusive，WE）
适用对象：
行
描述：
锁的拥有者可以读取和更改被锁定的行。
当向非目录表中插入行时，该行上将获得这种锁。
锁状态（模式）：
超级互斥（SuperExclusive，Z）
适用对象：
表空间和表
描述：
锁的拥有者可以更改表、删除表、创建索引或删除索引。
当事务尝试执行上述任何一种操作时，表上就自动获得这种锁。
在除去这个锁之前，不允许其它并发事务读取或更新该表。
db2的机制和oracle的也比较相似，
在具体执行前也是先根据表级锁的兼容性判断来确定事务是否等待，当然还要再根据行级锁来判断，同时当前事务也可以自动提升或人为提升表级锁的级别，通过这些手段来保持数据一致性。
db2中有很多类型的锁，并非单纯的就是“行级为独占锁，表级为意向所”
具体你可以参考一下db2的帮助。
当多个用户访问同一数据库时会发生的现象
使用单用户数据库时，每个事务都是顺序执行的，而不必应付与其它事务的冲突。
但是，在多用户数据库环境下，多个事务可以同步执行，并且每个事务都有可能与其它正在运行的事务发生冲突。
在多用户环境下，如果不将事务彼此隔离开来，就会发生四种现象：
（1）丢失更新：
这种事件发生在两个事务读取和尝试更新同一数据时，其中一个更新会丢失。
例如：
事务1和事务2读取同一行数据，并都根据所读取的数据计算出该行的新值。
如果事务1用其新值更新该行以后，事务2又更新了同一行，则事务1所执行的更新操作就丢失了。
由于设计的方法，DB2通用数据库不允许发生此类现象。
（2）脏读：
当事务读取尚未提交的数据时，就会发生这种事件。
例如：
事务1更改了一行数据，而事务2在事务1提交更改之前读取了已更改的行。
如果事务1回滚该更改，则事务2就会读取被认为是不曾存在的数据。
（3）不可重复的读：
当一个事务两次读取同一行数据，但每次获得不同的数据值时，就会发生这种事件。
例如：
事务1读取了一行数据，而事务2在更改或删除该行后提交了更改。
当事务1尝试再次读取该行时，它会检索到不同的数据值（如果该行已经被更新的话），或发现该行不复存在了（如果该行被删除的话）。
（4）幻像：
当最初没有看到某个与搜索条件匹配的数据行，而在稍后的读操作中又看到该行时，就会发生这种事件。
例如：
事务1读取满足某个搜索条件的一组数据行，而事务2插入了与事务1搜索条件匹配的新行。
如果事务1再次执行产生原先行集的查询，则会检索到不同的行集。
（5）两次更新问题（Secondlostupdatesproblem）：
无法重复读取特例，有两个并发事务同时读取同一行数据然后其中一个对它进行修改提交而另一个也进行了修改提交这就会造成第一次写操作失效
锁
所谓锁就是事务T在对某个数据对象——例如表、记录等——操作之前，先向系统发出请求，对其加锁，加锁后事务T就对该数据对象有一定的控制，在事务T释放它的锁之前，其它事务不能更新此数据对象。
基本的封锁类型有两种：
排他锁（ExclusiveLocks，简称X锁）和共享锁（ShareLocks，简称S锁）。
排他锁又称为写锁，若事务T对数据对象A加上X锁，则只允许T读取和修改A，其它任何事务都不能再对A加任何类型的锁，直到T释放A上的锁。
这就保证了其它事务在T释放A上的锁之前不能再读取和修改A。
共享锁又称为读锁，若事务T对数据对象A加上S锁，则事务T可以读A但不能修改A，其它事务只能再对A加S锁，而不能加X锁，直到T释放A上的S锁。
这就保证了其它事务可以读A，但在T释放A上的S锁之前不能对A做任何修改。
锁的兼容性
Java代码
1. X S －
2.X N N Y
3.S N Y Y
4.－ Y Y Y
XS－
XNNY
SNYY
－Y
升级会员 