Question

我目前正在使用COBOL连接到DB2的系统。将通过以下语句启动示例浏览：

       EXEC SQL
         DECLARE <cursor name> CURSOR FOR
         SELECT
             <field names>
         FROM <table name>
         WHERE
             <conditions>
         ORDER BY
             <key fields>
         FOR FETCH ONLY
         OPTIMIZE FOR 1 ROW
       END-EXEC.

       EXEC SQL
            OPEN <cursor name>
       END-EXEC.

确定浏览成功后，将使用以下内容成功读取表格：

       EXEC SQL
         FETCH <cursor name>
         INTO
             <variable names>
       END-EXEC.

例如，如果我浏览表格并且返回的结果集大约为100,000行，则需要数小时才能处理。如果我能确保系统的其他用户在我正在浏览的同一个表上进行处理（处理意味着选择，更新并可能删除记录），那么这可以确保系统的其他用户不会遇到死锁（-911）。

如何确定我正在执行的浏览操作是否可能导致其他用户死锁？

（注意：我没有做任何更新，只是纯粹检索数据）

Answer 1

帮助查找潜在死锁问题的一个工具是EXPLAIN的输出。与您的DBA交谈。

您说您的结果集可能是100,000行。不要那样做。没有用户会滚动那么多行。添加其他选择条件以允许它们过滤结果集。

您不会在结果集上保持锁定。我看到的一种技术是仅检索足够的数据以供用户进行选择，然后在进行选择时检索其余数据。

Answer 2

在大型机环境中，性能是全部！这不是因为大型机很快我们可以忽略性能要求。

在ONLINE程序中，我重新使用

FETCH FIRST N ROWS ONLY

用户页面大小为N-1。如果您成功获取光标中的N行，则会有更多页面，并且您会以某种方式通知您的用户。

DB2 QUERIES中的

;

如果您处于BATCH处理，最好使用DB2 Utility或DFSORT / ICETOOL / SYNCSORT使用适当的DD SORTDBIN传递SQL查询来卸载数据。

Answer 3

如果您只是在进行浏览操作，则“FOR FETCH ONLY”（也称为FOR READ ONLY）子句非常有用。如果包绑定上设置的隔离级别允许，您可能还需要查看“SKIP LOCKED DATA”子句以及“WITH UR”（未提交读取）的隔离级别。

所有这些假设您的业务规则将允许您仅处理其他进程目前未使用的脏行。

如果在完成所有这些操作后仍然看到死锁，您可以考虑将您的curson转换为声明的临时表并以此方式进行处理。这样可以保证您的数据没有其他读者或编写者，而代价是额外的DASD和核心资源。

Answer 4

如果表包含100,000行，则很可能您将“过滤”FETCH以选择进行演示。如果可能的话，在SQL SELECT中包含“过滤”信息。您的DBA看到的事务统计信息将确定其他INDEX BY语句是否会使事务更好地运行。

如何确定使用DB2 CICS的COBOL程序是否会导致其他事务死锁？

4 个答案: