从 Oracle 数据库迁移到 IBM DB2 on z/OS 并非完全无缝，必须进行精心策划。由于两种数据库之间存在锁定差异，因此当从 Oracle 向 DB2 on z/OS 迁移时，管理员可能会面临各种问题（参见表 1）。不过，这些问题在很大程度上是可以缓解的。
Oracle 与 DB2 on z/OS 之间的主要锁定行为差异之一在于：Oracle 不会在阅读时对行进行任何锁定，而 DB2 却会。这种差异可能导致出现锁等待和相关问题（如从 Oracle 向 DB2 迁移的应用程序中出现死锁和超时）的几率增加。
&">nbsp; Oracle DB2 on z/OS 1 除非 FOR UPDATE 子句明确要求，否则读取查询不会对行执行任何锁定。 默认情况下，读取查询持有共享级锁。 2 只有行级锁可以隐式执行。如果需要，可以显式锁定整个表。 默认锁为页面级锁，但也可以在行、表、表空间和 LOB 级别上应用锁。 3 不存在锁升级概念。 如果锁数目增加，则可以执行锁升级。升级结果会促使行级锁升级为表级锁和页面级锁，
然后再升级到表空间级锁，这样可降低锁数目。 4 由于不存在未提交读取概念，
所以无法执行脏读。 可以执行未提交读取，并且脏读是读取不带共享级锁的行的一种方法。
表 1. Oracle 与 DB2 on z/OS 之间的关键锁定差异
要处理锁定问题，需要在数据库、应用程序和操作级别上实施迁移策略。
数据库级策略
以下几种类型的数据库和设计更改有助于缓解锁定问题：
行级锁。覆盖默认的 DB2 页面级锁设置并进行重组，以便表运用行级锁定提高并发性。行级锁应当谨慎使用，因为锁数增加可能会导致开销增加，如果未能妥善处理，则势必会造成锁升级增加。
索引和查询优化。读取查询（可能需要执行表扫描）不会造成 Oracle 问题，却会导致 DB2 on z/OS 出现问题，因为读取查询会锁定整个表。为了缓解这个问题，需要确保已经优化了所有查询的索引和访问路径，从而避免不必要的表扫描，尤其是在线交易过程中访问的表扫描。
分区。在 DB2 for z/OS 中引入分区表空间后，并发性将得到大幅提升，批量运行尤为明显。通过确定分区键并根据键值范围将数据分别置于不同的分区，可以将数据划分为不同的分区。在进行批处理时，可以根据分区键值启动多个线程，这样不同线程就可以访问不同分区并提供更高的并发性。
应用程序级策略
某些关键8639.html">应用程序设计更改可能有助于缓解锁定问题，这些更改包括：
跳过锁定数据。您可能遇到过这样一种情况：同一表执行不同的事务，您只需访问所有给定表中当前未锁定的行。在这些情况下，DB2 提供了一个选项，通过使用 SELECT、UPDATE 和 DELETE 子句中的 KIP LOCKED DATA 选项仅查询未锁定的行。此选项只有在设置游标稳定性 (CS) 和读取稳定性 (RS) 隔离级别的情况下才适用，并且仅适用于行级锁和页面级锁。
未提交读取。在某些情况下，如果读取查询响应包含未提交数据是可以接受的，那么请尝试使用 WITH UR 选项在 DB2 中读取查询，因此它不具有任何共享锁。对于用户验收测试或生产区域内的应用程序测试人员和业务分析师，此选项在运行用户查询时十分有用。这些查询可能与应用程序查询彼此抗衡，因而，运行采用了 WITH UR 子句的用户查询可能需要避免出现这种状况。
表访问顺序。由于并行事务表的访问顺序不当，从 Oracle 向 DB2 for z/OS 迁移时也又可能发生锁争用现象。使访问顺序一致有助于避免发生这种问题。例如，如果事务 1 先访问表 A，再访问表 B，后续事务访问同样的表时也应当采用相同的顺序。
操作级策略
由于同一表执行不同类型的工作负载（例如，批处理和在线工作负载同时访问表，或者不同批次同时访问表），因此可能发生争用现象。在这些情况下，一种方法是执行操作级更改，如重新安排发生冲突的事务。同时也可以在非高峰期（当在线工作负载不运行）时运行批处理工作负载。如果两个批次并行运行，则尝试一前一后运行，或者设置依赖关系，以便一个工作负载无法在另一工作负载运行时运行，反之亦然。
结束语
Oracle 与 DB2 on z/OS 之间存在一些主要锁定差异，因此，当应用程序从 Oracle 向 DB2 迁移时，可能会导致锁定问题。不过，正如本文所述，我们可以在数据库、应用程序和操作级别上执行一些方案，极大地缓解可能出现的任何问题。