0

我目前正在开发一个使用 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），这将是可以的（处理意味着选择、更新和可能删除记录）。

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

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

4

4 回答 4

1

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

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

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

于 2014-10-15T12:01:31.907 回答
0

在大型机环境中，性能就是一切！这并不是因为大型机速度很快，我们可以忽略性能要求。

在在线程序中，我建议使用

FETCH FIRST N ROWS ONLY

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

在您的 DB2 查询中；

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

于 2014-10-16T01:53:20.777 回答
0

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

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

如果在完成所有这些操作后，您仍然看到死锁，您可能会考虑将您的 curson 转换为已声明的临时表并以这种方式进行处理。这将保证您的数据没有其他读取器或写入器，但会牺牲额外的 DASD 和核心资源。

于 2014-11-28T17:42:03.447 回答
0

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

于 2017-03-28T02:59:33.083 回答