0

COBOLバッチプログラムでは、パフォーマンスの点で何が優れていますか？

コミットあり：

IF SW-NEW-TRANSACT
  EXEC SQL
      COMMIT
  END-EXEC
END-IF.
PERFORM SOMETHING
   THRU SOMETHING-EXIT.
IF SW-ERROR
  EXEC SQL
      ROLLBACK
  END-EXEC
END-IF.

同期点の場合：

IF SW-NEW-TRANSACT
  EXEC SQL
      SAVEPOINT NAMEPOINT ON ROLLBACK RETAIN CURSORS
  END-EXEC
END-IF.
PERFORM SOMETHING
   THRU SOMETHING-EXIT.
IF SW-ERROR
  EXEC SQL
      ROLLBACK TO SAVEPOINT NAMEPOINT
  END-EXEC
END-IF.
4

2 に答える 2

5

SAVEPOINT と COMMIT は交換できません。

プロセスは常に、ある時点でデータベース作業を COMMIT または ROLLBACK する必要があります。COMMIT は、トランザクション間 (完全な作業単位間) で行われます。COMMIT は、各トランザクションの後、またはバッチ処理で一般的であるように、いくつかの複数のトランザクションの後に実行される場合があります。トランザクションの途中で COMMIT を行うべきではありません (これは UNIT OF WORK の概念に反します)。

SAVEPOINT は通常、1 つの作業単位内で取得され、場合によっては解放されます。SAVEPOINT は、作業単位の完了時に常に解放する必要があります。それらは常に COMMIT で解放されます。

SAVEPOINT の目的は、作業単位内からの部分的なバックアウトを可能にすることです。これは、一連の一般的なデータベースの挿入/更新でプロセスが開始され、その後にプロセス分岐が続き、代替プロセス分岐が実行されるべきであると判断される前に更新が実行される可能性がある場合に役立ちます。SAVEPOINT を使用すると、「袋小路」分岐から戻って、共通の「前もって」作業を維持しながら代替分岐を続行できます。SAVEPOINT がなければ、「袋小路」から戻るには、トランザクション内で大規模なデータ バッファリング (複雑な処理) が必要になるか、代替プロセス ブランチが必要であることを示す何らかのフラグを使用して、トランザクションの開始から ROLLBACK とやり直しが必要になる可能性があります。従うこと。これらすべてが複雑なアプリケーション ロジックにつながります。ROLLBACK TO SAVEPOINT にはいくつかの利点があります。「事前の」作業を維持できるため、やり直すコストを節約できます。トランザクション全体をロールバックする手間を省きます。ロールバックは、元の挿入/更新よりも「高価」になる可能性があり、複数のトランザクションにまたがる可能性があります (コミットの頻度によって異なります)。最後に、ROLLBACK TO SAVEPOINT を使用してデータベース作業を選択的に「元に戻す」ことができると、一般にプロセスの複雑さが軽減されます。

バッチ プログラムの効率を向上させるために SAVEPOINT をどのように使用できますか? トランザクションが自己誘導ロールバックを使用して「袋小路」処理から回復する場合、SAVEPOINT は大きなメリットとなります。同様に、同様の「バックアウト」要件のためにデータベースの更新を実行することを避ける必要があるために内部処理ロジックが複雑である場合、SAVEPOINT を使用して、プロセスをかなり単純でおそらくより効率的なものにリファクタリングできます。これらの要因以外では、SAVEPOINT がパフォーマンスに良い影響を与えることはありません。

バッチ プログラムで COMMIT の頻度が高いと、パフォーマンスが低下すると主張する人もいます。したがって、コミット頻度が低いほど、パフォーマンスは向上します。COMMIT 頻度のチューニングは簡単ではありません。コミット頻度が低いほど、データベース リソースが保持される時間が長くなるため、データベース タイムアウトが発生する可能性が高くなります。通常、データベース タイムアウトが発生すると、プロセスがロールバックします。ロールバックは非常にコストのかかる操作です。ROLLBACK は DBMS 自体に大きな打撃を与えるため、トランザクションを再起動すると、すべての更新をもう一度適用する必要があります。コミット頻度を下げると、得られるよりもはるかに多くのコストがかかる可能性があります。注意！

編集

経験則: コミットにはコストがかかります。ロールバックのコストは高くなります。

不正なデータ、デバイスの障害、プログラムの異常終了 (これらはすべてまれです) によるロールバックを差し引いても、ほとんどのロールバックは、プロセス間のリソースの競合によるタイムアウトによって引き起こされます。コミット数を減らすと、データベースの競合が増加します。コミット数を減らすと、パフォーマンスが向上する場合があります。秘訣は、コミットしないことで得られるパフォーマンスが、競合によるロールバックのコストをどこに加味するかを見つけることです。これに影響を与える要因は多数ありますが、その中には動的なものもあります。私の全体的なアドバイスは、パフォーマンスを改善するために他の場所を探すことです.コミット頻度の調整（タイムアウトが問題ではない場合）は、一般的に投資収益率が低くなります。

バッチのパフォーマンスを改善するためのその他のより有益な方法には、多くの場合、次のものが含まれます。

  • 負荷分割と同じジョブの複数のイメージの実行による並列処理の改善
  • db/2 バインド プランの分析とアクセス パスの最適化
  • バッチ プログラムの動作をプロファイリングし、最もリソースを消費する部分をリファクタリングする
于 2012-04-10T14:33:56.467 に答える
1

これはまったくパフォーマンスの問題ではありません。

作業単位がアプリケーションにとって何を意味するかに関係なく、作業単位を完了するとコミットします。通常、これは完全なトランザクションを処理したことを意味します。バッチの世界では、1,000 から 2,000 のトランザクションの後に commit を行うため、COMMIT にすべての時間を費やすことはありません。この数は、ROLLBACK の場合に再実行できるトランザクションの数によって異なります。

データベースエラーまたはアプリケーションエラーのいずれかのエラーが発生した場合、ロールバックします。

複雑な作業単位を処理しているときにSAVEPOINTを実行し、完了した内容を完全な COMMIT を実行せずに保存したい場合。つまり、1 つ以上の SAVEPOINT を取得してから、最後に COMMIT を取得します。

于 2012-04-09T14:03:45.500 に答える