前言
揭示这种神秘锁和其他 DB2 for z/OS 难题的真实面目。
SIX 锁是 DB2 的许多神秘特性之一。它是什么？如何获得它？另一个神秘特性是 plan_table 上的 index_only 标志：对于 UPDATE 或 DELETE，为何要设置为 Y？再问一下，UPDATE 或 DELETE 为何一定就是 “index-only”？第三个神秘现象是，在 SQL 语句中添加 ORDER BY 可能消除排序。更奇怪的情况是，删除 ORDER BY 子句实际上可能在访问路径中增加排序。在后面几篇专栏文章中，我将讨论这些神秘现象并尝试解决它们。现在让我们当一回少女神探 Nancy Drew，开始探索神秘的 SIX 锁。
SIX 锁
在以前的专栏文章（“表空间和锁级别，第 1 部分”，2005 年第 1 期）中，我通过类比解释了 DB2 锁：把建筑物比作表空间，把楼层比作表，把房间比作页。用户必须先进入建筑物，然后进入某一楼层，最后进入房间。同样，在使用页级锁时，无法直接进入页。必须先进入表空间（相当于建筑物），然后进入表（相当于楼层），最后进入页（相当于房间）。典型的更新者首先请求一个表空间锁，然后请求表锁，最后请求页锁。外层（即高级）锁称为 “Intent Lock（意向锁）”。如果进入页，您的意图便是获得页级锁。例如，可能必须获得表空间上的 IX 锁（希望执行某些特定的操作；I 表示 Intend，X 表示 eXclusive），然后获得表上的 IX 锁，最后再获得页上的 X（exclusive）锁。
通常情况下，对于执行维护的用户，需要表空间和表上的 IX 锁；对于只执行读操作的用户，需要 IS（Intend to Share）锁。但是，对于这两种情况，在这些级别上都会看到 SIX 锁。这种锁是什么？它有什么作用？
只能读，不能进行更新
2 3 4 下一页</div> </div> </div> </div> </div>