COMMIT/ROLLBACKとROLLBACKのパフォーマンスをSAVEPOINTにバッチする

Question

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. 

Answer 1

SAVEPOINTとCOMMITは互換性がありません。

プロセスは、ある時点で常にCOMMITまたはROLLBACKデータベースの作業が必要です。 COMMITはとなり、トランザクション（作業単位の間）でとなります。 COMMITは、各トランザクションの後、またはバッチ処理では一般的に、いくつかの複数のトランザクションの後に の後に取られることがあります。 COMMITはトランザクションの途中で行われることはありません（UNIT OF WORKのコンセプトに反する）。

一般に、SAVEPOINTは、の単一の作業単位で取られ、リリースされる可能性があります。 SAVEPOINTは、作業単位の の完了時に常に解放されるべきです。それらは常にコミット時に解放されます。

SAVEPOINTの目的 は、作業単位内で部分バックアウトを許可することです。これは、プロセスが一連の一般的な データベースの挿入/更新で始まり、プロセスブランチが続き、いくつかの更新が実行され、代替プロセス ブランチが実行されている必要があると判断できる場合に便利です。 SAVEPOINTは、 "ブラインド路地"ブランチから退出し、次に共通の "前部"作業を維持しながら、代替の ブランチで継続することができます。 SAVEPOINTがないと、「盲目的な路地」からのバックアウトは、トランザクション（複雑な処理）またはROLLBACK内で大量のデータをバッファリングする必要があり、何らかの種類のフラグ でトランザクションの開始からやり直す必要があるかもしれません支店をフォローする必要があります。このすべてが複雑なアプリケーションロジックにつながります。 ROLLBACK TO SAVEPOINTにはいくつかの利点があります。 "前部の作業"を保存することができ、作業のコストを節約できます。トランザクション全体をロールバックして保存します。ロールバックは、オリジナルの挿入/更新よりも "高くなりました（）可能性があり、複数のトランザクションにまたがることがあります（コミット頻度に応じて）。 最後に、データベースの作業がROLLBACK TO SAVEPOINTを介して選択的に "元に戻す"ことができる場合、プロセスの複雑さは一般的に減少します。

SAVEPOINTを使用してバッチプログラムの効率を上げるにはどうすればよいですか？あなたのトランザクションが「盲目的な処理」から を回復するために自己誘導ロールバックを採用した場合、SAVEPOINTは大きな利点となります。同様に、内部処理ロジックが複雑になる場合は、SAVEPOINTを使用して、プロセスを にリファクタリングすることができます。これはかなり簡単で効率的なものです。これらの要因の外に、SAVEPOINTはパフォーマンスに影響を与えません 肯定的な方法で。

バッチプログラムでCOMMIT頻度が高いと、パフォーマンスが低下することがあります。したがって、コミット頻度が低いほど、パフォーマンスは向上します。 コミット頻度を調整することは自明ではありません。コミット頻度が低いほど、より長いデータベース・リソースが保持され、その結果、データベース・タイムアウトを引き起こす可能性が高くなります。データベースのタイムアウトが発生すると、通常はプロセスがロールバックされます（ ）。ロールバックは非常に高価な操作です。 ROLLBACKはDBMSにとって大きな打撃を与えており、 トランザクションを再起動すると、すべての更新を再度適用する必要があります。コミット頻度を下げると、それ以上に多くの費用がかかります。 注意してください！

EDIT親指の

ルール：コストを持ってコミットします。ロールバックはコストが高くなります。

不良データ、デバイス障害、およびプログラム異常終了（いずれも稀でなければなりません）のためにロールバックを割り引くと、ほとんどのロールバックはプロセス間のリソース競合により、 タイムアウトによって引き起こされます。コミット回数を減らすと、データベースの競合が増えます。 をコミットすると、パフォーマンスが向上する可能性があります。トリック は、競合によるロールバックのコストに重み付けをしないことで得られたパフォーマンスを見つけることです。そこには がこれに影響を与える多数の要素です - 動的かもしれません。私の全体的なアドバイスは、パフォーマンスを向上させるために を探すことです（タイムアウトは問題ではありません）。バッチpreformanceのを改善するための

他のより実りの方法は、多くの場合、関与：

• は、負荷分割によってparalleslismを改善し、同じ仕事
• の複数の画像DB/2バインド計画を分析し、アクセスパス
• をoptomizingを実行していますバッチプログラムの振る舞いをプロファイリングし、ほとんどのリソースを消費する部分をリファクタリングする

Answer 2

これがすべてでパフォーマンスの問題ではありません。

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

何らかのエラーが発生した場合は、データベースエラーまたはアプリケーションエラーのいずれかが発生したときにROLLBACKを実行します。

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