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

潜在的なデッドロックの問題を見つけるのに役立つツールの 1 つは、EXPLAIN からの出力です。DBA に相談してください。

結果セットが 100,000 行になる可能性があるとします。そうしないでください。それほど多くの行をスクロールするユーザーはいません。追加の選択基準を追加して、結果セットをフィルタリングできるようにします。

結果セットのロックを維持するつもりはありません。私が見たテクニックの 1 つは、ユーザーが選択できるように表示するのに十分なデータのみを取得し、選択が行われたときに残りを取得するというものです。

于 2014-10-15T12:01:31.907 に答える
0

ブラウズ操作を行っているだけの場合は、「FOR FETCH ONLY」(別名 FOR READ ONLY) 句が非常に役立ちます。パッケージバインドに設定されている分離レベルで許可されている場合は、「SKIP LOCKED DATA」句と「WITH UR」(非コミット読み取り) の分離レベルを調べることもできます。

これらはすべて、ビジネス ルールにより、他のプロセスが現在使用していないダーティ行のみを処理できることを前提としています。

これらすべてを実行してもまだデッドロックが発生する場合は、カーソルを宣言済み一時テーブルに変更し、その方法で処理を行うことを検討してください。これにより、追加の DASD およびコア リソースを犠牲にして、データに他のリーダーまたはライターがないことが保証されます。

于 2014-11-28T17:42:03.447 に答える
0

メインフレーム環境では、パフォーマンスはすべてです! メインフレームが高速だからといって、パフォーマンス要件を無視できるわけではありません。

オンラインプログラムでは、使用をお勧めします

FETCH FIRST N ROWS ONLY

ここで、ユーザー ページ サイズは N-1 です。カーソル内の N 行のフェッチに成功すると、さらにページがあり、何らかの方法でユーザーに通知します。

DB2 QUERIES で;

BATCH 処理を行っている場合は、DB2 ユーティリティーまたは DFSORT/ICETOOL/SYNCSORT を使用してデータを UNLOAD し、適切な DD SORTDBIN を使用して SQL 照会を渡します。

于 2014-10-16T01:53:20.777 に答える