DB2通用数据库的并发性

ACQUIRE/RELEASE 组合
%i)O.u%} g;{0
$C2o7|7ruU0对于 BIND 的 ACQUIRE/RELEASE 选项的通用建议是基于应用程序的特点选择组合值。有一种组合，即 ACQUIRE(ALLOCATE)/RELEASE(COMMIT) 是不允许的。DB2 BIND 进程会将该种说明标记为错误。其他三种可能的组合都有其合适的用法，下面将简要地进行描述。
w:b s9W L0
'?&RZjf@8P0    * ACQUIRE(ALLOCATE)/RELEASE(DEALLOCATE)
8b cr&c$@m3I
h0
/W!z/`8H;t4_0ACQUIRE(ALLOCATE)/RELEASE(DEALLOCATE) 可能对于运行几小时并访问不同表的批应用程序十分有用，因为该组合将有效地阻止死锁状况损耗一切处理。一开始运行程序，应用程序就会锁定所有所需资源。ITPUB个人空间Gk/A6Kz#v.og
ITPUB个人空间!ZZ3Dy4Lz#yI
该组合的不足就是它可能严重地减小并发性。 潜在地具有较高需求的资源的锁定时间可能比实际所需要长。同时，请注意 ACQUIRE(ALLOCATE) 禁用选择性的分区锁定，以至于如果您访问用 LOCKPART YES 定义的表空间，将会锁定所有分区。
dXs%^1Bv0ITPUB个人空间.d!Yu`Fc]
    * ACQUIRE(USE)/RELEASE(DEALLOCATE)
rw,I/[&D"H/xmIB0
p6[$@.rO0e n0ACQUIRE(USE)/RELEASE(DEALLOCATE) 组合通常导致最为高效地使用处理时间。DB2 UDB 资源仅在应用程序需要它们时才被锁定。这样就减小了锁开销，因为在那之后，会将所获取的锁保留到终止应用程序之时。
]w"K9V%D&C0
Q;i!KI6l3c.ao3c0该组合的不足就是相较于 ACQUIRE(ALLOCATE) 时，它可能导致更频繁地发生死锁状况。只有在实际的应用程序运行时，才按可预测的次序这样来作用所获取的锁。因此，可能发生更多死锁。
f+s:E%zc0E0ITPUB个人空间6ZP}9keB.OQ`
    * ACQUIRE(USE)/RELEASE(COMMIT)ITPUB个人空间mN&k8SJ-dT(t+zj%}
ITPUB个人空间ls6sv7zKj1e
ACQUIRE(USE)/RELEASE(COMMIT) 碰巧就是 BIND 的默认组合，提供了最佳的并发性。DB2 UDB 资源仅在应用程序需要它时才被锁定，如果该应用程序包含许多不常使用的 SQL 语句，这就可能极其重要。
8F&`"|K-Pl*i7c0
5tM3fHeZ`Y0然而，其权衡就是，如果应用程序相当频繁地提交，就可能增加处理时间，那么该应用程序就必须再次重新获取锁。与上面的 ACQUIRE(USE)/RELEASE(DEALLOCATE) 组合一样，也可能增加死锁，因为只有在执行实际的程序时，才按可预测的次序获取所有的锁。
V5m&aE:] Y6jCl]0
xaLy2a UgM0D[d0ISOLATION
Too-wV/h'h8}0G"y0
+_9F3}6[k0参数 ISOLATION 决定 DB2 UDB 为保护一个应用程序所用数据，防备该 DB2 UDB 系统里的其他应用程序，而维护的保护或隔离程度。下面完全从并发性角度出发，按照递增的优先级列出了 4 个选项：
:i*\a8A7]Z@(s0
1Sf0^B$M0   1. ISOLATION(RR)
P4a4arp.A%c@!Ki0
t&S9fW*Rrp0      通过可重复读（Repeatable Read，RR），要用行锁或页面锁锁定应用程序所访问的所有行（无论是否为限定的），并至少保持到下一提交点。DB2 UDB 确保：ITPUB个人空间5o.m!p)l\sf$A
          * 您的应用程序不读取另一应用程序进程修改的那一行，直到该进程释放该行，并且
z'Q|@`3ER!b"F0          *ITPUB个人空间1W"XoyK#}

"DWb
D-w'r0W2e'?0            其他应用程序进程不修改您的应用程序所读取的那一行，直到应用程序进行了提交或终止。
t*Z2sz4NG@8g@0   2. ISOLATION(RS)
BY$}p^cBI0ITPUB个人空间/i|K os5r
      通过读稳定性（Read Stability，RS），要用行锁或页面锁锁定所有返回给应用程序的限定行，并至少保持下一提交点。DB2 UDB 确保：ITPUB个人空间+HV?
X jFG b ^
          * 您的应用程序不读取另一应用程序进程修改的那一行，直到该进程释放该行，并且ITPUB个人空间"[v
zOY&UFC
          *ITPUB个人空间af1G&||S
ITPUB个人空间2a5A,pG%A+y C~%Q
            其他应用程序进程不修改满足您应用程序的搜索规则（由 WHERE 从句决定）的那一行，直到应用程序进行了提交或终止。它允许其他应用程序进程 INSERT 一行或 UPDATE 现有的行，只要该行原来不满足其搜索规则。ITPUB个人空间9}'{r0Gd'O~
   3. ISOLATION(CS)ITPUB个人空间T!]4U{%kg#lO)] w;J}
ITPUB个人空间 bt bN [W a6h&LI5J
      通过游标稳定性（Cursor Stability，CS），仅仅将行锁或页面锁保留到游标移动到另一行或另一页。因此，DB2 UDB：
pO'|)f`(Y7~}`J_'{0          * 确保您的应用程序不读取另一应用程序进程修改的那一行，直到该进程释放该行，但是
+wS4dp9c0          *
!A p|Q r^0ITPUB个人空间]6A3M)} }u7r
            允许其他应用程序进程在您的应用程序进行了提交或终止之前，修改您的应用程序所读取的那一行。
OiS7A3j~D r9\6H0   4. ISOLATION(UR)
1_ T7Wd)xzw0
{c+un'y9`0      通过未提交读（Uncommitted Read，UR），DB2 UDB 不获取任何行锁或页面锁（除了对于 LOB 数据），且可以与大多数其他操作并发运行。在 I/T 行业中，这常常称作“脏读”。通过该隔离级别，DB2 UDB 允许：
,l+X;WJjR
BwQU,c0          * 其他应用程序进程修改您的应用程序在工作单元期间可能读取的行。ITPUB个人空间:e7M;WK)s!j
          * 您的应用程序读取另一应用程序进程所修改的那一行，即使该修改还未被提交。
*_{
o$|,yX'B0
%@Q}Nz s(b\b|0CURRENTDATAITPUB个人空间]-FX~|)S4]7__6|

!mcB!K7jF)u0该选项仅适用于 ISOLATION(CS)。对于与游标稳定性（Cursor Stability）绑定的应用程序中的只读和歧义游标，该选项决定是否需要数据并发性。换言之，它告诉 DB2 UDB 该游标所定位数据是否必须与基表中的数据保持一样（或“相容”）。进一步需要阐明的是，对于歧义游标，DB2 UDB 无法确定是将它用于更新还是将它用于只读目的。
o j(LCQP5EBE0ITPUB个人空间 Rz&v}~k
CURRENTDATA(YES) 指定需要数据并发性，以致 DB2 UDB 将获取页面锁或行锁来确保这一点。CURRENTDATA(NO) 指定不需要数据并发性，因此，DB2 UDB 不会获取那些锁。
"nnQD9E7t`+Thh+T0ITPUB个人空间km"k3Xd`/\e
重写隔离（WITH 从句）
?6| s'GcY4Py^0
L
SRP$F6I0DB2 UDB 允许应用程序里的 SQL 语句指定所绑定计划或包的隔离级别。这将有效地重写用于计划或包的隔离级别，但仅仅是在它出现的语句中。WITH 从句可以用于下列类型的 SQL DML 语句：
:^)oh u
`lJ4Z;n0ITPUB个人空间1B#{mv"Y
iLw-X{
    * SELECTITPUB个人空间 CFr OW~?#k-u(C6M#Z
    * “搜索的”UPDATE 和 DELETEITPUB个人空间j7kw7{:{-~0]&ISNZ
    * 子查询中的 INSERT
!iUi6|XYj0
{\"pG+f1n0ISOLATION 建议ITPUB个人空间8d3S:e^hM
ITPUB个人空间j9b9Gu g-JWm&Cx/a
合适的 ISOLATION 选项需要通过应用程序的业务逻辑和数据完整性需求来决定。该决定需要对应用程序需求和相关的业务规则具有基本理解。
CS/Xgh"v#M#j9?-u|0ITPUB个人空间1g,YEFkTL
通常，您应该使用最少的限制隔离，它仍将维护应用程序的数据完整性需求。隔离的限制越少，数据的并发性就越高，因而访问 DB2 UDB 数据的性能就越好。通常，ISOLATION(CS) 与 CURRENTDATA(NO) 将是一个较好的起始点。ISOLATION(CS) 允许 DB2 UDB 尽快释所获取的锁，而 CURRENTDATA(NO) 允许 DB2 UDB 避免过于频繁地获取锁。
^2T,E&oPL:q0
3{7i5r$b6DY+}\0未提交读（Uncommitted Read，UR）极其高效，仅导致少量竞争或不导致竞争，但是，它的使用应极为谨慎，因为它使 DB2 UDB 能够读未提交的数据。一般不推荐使用 ISOLATION(UR)，除非已经确定应用程序和终端用户可以接受 UR 所允许的逻辑数据不一致性。
qbg#U|Y%]X0
G*P_ P Z8B0锁避免和隔离
L/uF0Hw3Dt:Hl0ITPUB个人空间[C~g*@
锁避免是在 DB2 V3 中引入的并发性提高。它使 DB2 UDB 在确定某页中的数据已经提交之后，就能够读取该页面，而无需获得锁。是否可以使用锁避免取决于应用程序在其 SQL 调用中使用的隔离程度。ITPUB个人空间|0t&XF/b,t{Z5}

DCM/kjCo(l7T s0ISOLATION(RR) 和 ISOLATION(RS) 不允许任何锁避免。带有 ISOLATION(CS) 的游标对非限定的页面或行使用锁避免。带有 ISOLATION(CS) 和 CURRENTDATA(NO) 的歧义游标和只读游标对限定的和非限定的页面或行均使用锁避免。
xw$j0^.G ^ nK t0
&D)R#eBG~0~
X[w#u R0限制表空间上的锁
8q6r(J!l~`z%u,?0
G%kP:i%Mb&N ]0LOCKMAX 是一个可以在 CREATE 或 ALTER 表空间时指定的选项。这指定在进行锁升级之前，单个应用程序可以持有的 DB2 UDB 表空间上的页面锁或行锁的最大数目。该选项可以同时对用户数据和 DB2 UDB 编目生效。ITPUB个人空间&{},A5}G,G

#TU:A#i;]!zJ k0如果 n表示发生锁升级之前页面锁或行锁的最大数目，那么就指定 LOCKMAX n。通过指定 LOCKMAX 0 可禁止锁升级。指定 LOCKMAX SYSTEM 是将最大数目设置为系统默认值，而系统默认值是由安装面板的 DSNTIPJ 上的选项 LOCKS PER TABLE(SPACE) 设置的。
3M$a*`R w ~h6bb:X0
D#w }!XmK/bA0限制应用程序获取的锁ITPUB个人空间3pH.?[ |

us]$Xi&yK0DB2 UDB 还允许设置单个应用程序持有的页面锁或行锁的最大数目。该选项 LOCKS PER USER 也位于安装面板 DSNTIPJ 上。如果一个应用程序进程已经持有所指定的最大数目，但又向 IRLM 请求一个页面锁或行锁，那么 DB2 UDB 就会向该应用程序的 SQLCA 发送一条错误消息。直到释放某些现有的锁之后，才可以获取所请求的锁。ITPUB个人空间DJbf0bW(j4P
ITPUB个人空间-b Tv _0`o&Z]
默认的 LOCKS PER USER 为 10,000。当使用页面锁时，该数字对于大多数装置的多数工作负载来说通常已经足够了。对于极其大型的表上的行级锁或 LOB 来说，可能有必要指定一个更大的值。或者，您可能需要查看需要更大值的应用程序类型，并分析它们是否可以使用表空间锁来代替页面锁、行锁或 LOB 锁。