ibm-midrange - iSeries数据源锁定

Question

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

谢谢。

Cognos 10.1.0 ....
iSeries V7R1M0

巴克
感谢您抽出宝贵的时间来评论...。但是，我向您保证我的iSeries实际上正在运行V7R1M0，并且我从未说过我拥有记录锁定。我说过文件保持锁定。我非常确定我的问题确实提出了一个特定的方案，其中Cognos通过Client Access ODBC驱动程序访问AS400文件并锁定该文件。然后将锁保持一定时间。我的问题是，是否有一种方法可以阻止Cognos保持对该文件的锁定。锁定发生后，我可以为iSeries上的随机文件访问提供错误消息，但是由于我一直在寻找一种方法来在发生这些错误之前解除锁定，所以我没有看到它的意义...但是我敢肯定我将收到一个CPF3203错误，告诉我它无法分配对象。

Answer 1

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'从tempfile中删除'而不是CLRPFM TEMPFILE-作为SQL，它不需要对表进行* EXCL锁定。

编辑：RGZPFM

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

较新的应用程序可以在该行上执行实际的物理DELETE操作，但该行仍占用空间。磁盘仍然很昂贵，因此RGZPFM诞生了。 RGZPFM仍然需要对该表进行独占访问，原因与两步CPYF相同。这些RGZPFM流程中的许多流程只是简单地继承而未考虑在具有更多磁盘的更新（更快）硬件上进行实际重组的必要性。一些应用程序执行重组，因为“这就是我们一直这样做的方式”。

现在是2014年，硬件速度非常快，磁盘价格却很便宜。可以创建表以重用已删除的记录-这是使用CREATE TABLE创建的表的默认设置，并且极少数例外情况下不会出现性能问题-并且性能是RGZPFM的主要原因。 RGZPFM仍然有一个地方，该地方可用于具有许多已删除记录的大型表-稀疏表。如果您有一个SQL SELECT导致进行了全表扫描，那将会对性能产生影响。一般来说，这些表并不多。如果您有数百万个行表，则它可能是一个历史文件，并且看不到太多的DELETE活动。但这是针对稀疏表具有数百万行且没有根索引的少数情况的考虑。