4

我在我的 AS400 (iSeries) 上设置了一个数据源，当 Cognos 通过客户端访问 ODBC 驱动程序访问它时，它会锁定 AS400 上的文件。即使报告关闭，文件也会在一段时间内保持锁定状态。这会导致更新数据源、重新组织文件、清除记录等问题。必须有一种方法可以强制 ODBC 驱动程序在检索到数据时解除锁定......或者至少，监控时间它保持不变。任何方向将不胜感激。

谢谢。

Cognos 10.1.0.... iSeries V7R1M0

Buck，感谢您抽出宝贵时间发表评论……但是，我向您保证，我的 iSeries 实际上正在运行 V7R1M0，而且我从未说过我有记录锁。我说一个文件仍然被锁定。我很确定我的问题确实提出了一个特定场景，其中 Cognos 通过客户端访问 ODBC 驱动程序访问 AS400 文件并锁定文件。然后持有锁一段时间。我的问题是，是否有办法阻止 Cognos 保持文件上的锁定。在此锁定发生后，我可以为 iSeries 上的随机文件访问提供错误消息，但是当我正在寻找一种在这些错误发生之前解除锁定的方法时，我没有看到它的相关性......但我确信我会收到一个 CPF3203 错误，告诉我它无法分配对象。

4

1 回答 1

4

IBM i 7.1 不能在 AS/400 或 iSeries 硬件上运行。这不是语义上的问题：在 Web 上搜索 ODBC 和 AS400 将返回古老且无用的结果。

该问题不包括特定的错误消息，也不包括发生该错误的特定场景。我猜你在CLRPFM. 如果是这样，根本原因是数据库管理器没有完全关闭游标；出于性能原因，它会软关闭它们（有时称为伪关闭）。

如果您有一个非 SQL 进程需要对表进行排他锁（如SAVOBJ、CLRPFM、DLTF、RGZPFM等），那么您可以包含一个ALCOBJ带有参数设置的命令以强制关闭任何伪关闭游标。 ALCOBJ OBJ((SOMSCHEMA/SOMETABLE *FILE *EXCL)) WAIT(1) CONFLICT(*RQSRLS)

如果我猜错了，请编辑问题以显示在引发错误的 IBM i 端正在执行的操作，以及错误的确切错误消息 ID。

编辑：更好地解释锁定

任何 ODBC 访问、任何 RPG 记录级别访问、打开表进行输入的任何进程都会导致表锁定。如果 I/O 请求是只读的，则锁定级别为 *SHRRD（共享读取）。如果 I/O 请求涉及更新，则锁定级别为 *SHRUPD（共享更新）。这是正常且理想的行为，不能被禁用，因为它发生在操作系统的深处，并且存在于 IBM i 的 DNA 中。

这些对象锁允许共享访问；如果您的 Cognos 进程在表上具有 *SHRUPD 锁，那么我的 RPG 程序仍然可以同时打开、读取、写入和更新同一个表中的记录。这就是所有现代数据库的运作方式。

通常，当出现此类问题时，有一个服务器进程需要对表进行排他 (*EXCL) 锁定。典型的服务器端操作是 CLRPFM、RGZPFM、SAVOBJ。如果 Cognos 使用 *SHRUPD 锁打开表（WRKOBJLCK 会告诉您这一点），则像 CLRPFM 这样的服务器端进程无法获得 *EXCL 锁并将发出 CPF3203 - 无法为文件分配对象。

有时会丢失的部分是伪关闭。典型的 ODBC 过程可能如下所示：

  • ODBC 连接
  • 打开光标
  • 获取结果集
  • 关闭光标
  • ODBC 断开连接

在 DB2 方面，人们会期望当“关闭游标”步骤发生时，*SHRUPD 锁被释放。这不一定会发生，因为 DB2 执行伪关闭，将光标留在内存中，以便 Cognos 下次执行相同的访问（除了说，使用不同的客户）。对于大多数操作来说，这不是问题——当 Cognos 可以随时请求访问时，谁需要在表上使用 *EXCL 锁？但是我们的遗产并不那么简单，我们中的大多数人仍然有服务器端进程来执行快速 CLRPFM 以从工作表中清除一批。这就是 CPF3203 出现的地方。

由于数据库管理器持有锁（不是 Cognos 进程，它已断开连接！），我们需要告诉 DB2 我们希望在执行 CLRPFM 之前执行硬关闭。ALCOBJ CONFLICT(*RQSRLS) 就是我们这样做的方式。这需要在执行 CLRPFM 的 CL 程序中添加。解决此问题的另一种方法是使用 SQL 清除表。在 7.1 中，我们可以在 CL 程序中发出 SQL 命令，因此我们可以执行 RUNSQL 'delete from tempfile' 而不是 CLRPFM TEMPFILE - 作为 SQL，它不需要对表进行 *EXCL 锁定。

编辑：RGZPFM

可能有一些关于 RGZPFM 的背景知识。非常旧的应用程序不会删除表中的记录：它们设置了应用程序需要检查的“已删除记录”字节。随着时间的推移，这些表累积了越来越多的标记为已删除或非活动的记录。磁盘很贵，这些记录是多余的，所以重组诞生了。通常这是一个两步过程：将文件复制到临时副本，然后将其复制回来，省略“删除”。这工作正常，因为重组通常在晚上作为一天结束处理的一部分运行，此时交互式用户离开系统。另一个好处是将记录按主键顺序排列。这提高了按键阅读程序的性能。

更现代的应用程序能够对行发出实际的物理 DELETE 操作，但该行仍然占用空间。磁盘仍然很昂贵，因此 RGZPFM 诞生了。RGZPFM 仍然需要对表的独占访问权，原因与两步 CPYF 所做的相同。许多这些 RGZPFM 过程只是简单地继承下来，没有考虑在具有更多磁盘的更新（更快）硬件上进行实际重组的必要性。一些应用程序执行重组，因为“我们一直都是这样做的”。

现在是 2014 年，硬件真的很快，磁盘也很便宜。可以创建表以重用已删除的记录——这是使用CREATE TABLE. RGZPFM 仍然有一个位置，它用于具有许多已删除记录的大型表 - 稀疏表。如果你有一个导致全表扫描的 SQL SELECT，那将会对性能造成影响。一般来说，这些表并不多。如果您有一个数百万行的表，它可能是一个历史文件并且看不到很多 DELETE 活动。但是对于稀疏表具有数百万行且没有 goot 索引的少数情况，这是需要考虑的。

于 2014-05-08T17:14:20.927 回答