分散DB・2相コミット・NoSQL・DWH 重要度:★★★出題: PM1・PM2
べき等性（Idempotency）とAPI・バッチ再実行可能設計
べきとうせいとかいふくさいじっこうかのうせっけい / Idempotency & Restartable Batch Design
同じリクエスト（API呼出しやバッチジョブ）が通信タイムアウトや障害復旧によって複数回実行されても、1回実行したときと同じデータベース状態になるよう保証する設計性質。
3行速習ポイント
- API連携ではリクエストごとに一意な「指示番号（リクエストID）」を付与し、履歴テーブルに同一指示番号の行が既に存在すれば更新を行わず正常終了させる
- 大量データを更新するバッチ処理では、一定件数ごとにコミット（コミット間隔制御）してロック保持時間を短縮しつつ、「再開位置テーブル」や「次回処理日」を同一トランザクション内で更新する
- 異常終了後の再実行（リスタート）時に、コミット済みの行が再度処理対象として選択されない（二重加算されない）SQL条件にすることが不可欠
図解
図べき等APIとバッチ分割コミット・リスタート制御
11. 重複・再開位置チェック
Check要求IDの存在確認または再開位置テーブルから前回コミット済キーを取得
22. 一定件数処理＋進捗記録
Batch TxN件ごとの業務更新と再開位置更新（または処理済日付更新）を同一Tx内で実行
33. 異常終了後の安全な再実行
Idempotent Restartコミット済行はWHERE条件から除外され、未処理行のみから正確に再開
概要と本質
令和7年午後II問1（決済指示#による重複処理防止）や令和6年午後I問2（再開位置テーブルを用いたバッチ分割コミット）、令和6年午後II問1（次回報告YMDの更新による再実行時の二重作成防止）など、近年のDB午後試験で毎年出題されている超重要テーマです。
重要ポイント・コア概念
- APIのべき等性担保：“決済履歴”等のテーブルにリクエスト一意識別子（決済指示#）を主キーまたは一意制約付きで記録し、処理冒頭で一致する行があれば処理をスキップする
- バッチ分割コミットの再実行可能性（リスタート性）：一定件数ごとにCOMMITする場合、①処理済み行の属性（例：次回報告YMDや処理済フラグ）が更新されて再実行時のWHERE条件から自然に外れるか、②“再開位置”テーブルに処理済み最終主キー値を記録して次回はそこから再開する
- 全件完了時：“再開位置”テーブルの当該ジョブIDの行を削除（または初期化）して終了する
午後I・午後II記述試験での攻略ポイント
午後試験で「一定回数ごとにコミットする方式に変更した際、途中で異常終了して再実行しても二重登録にならない理由は何か」と問われたら、『更新をコミットした行は属性値が更新されており、再処理時の抽出条件で選択されないから』と、抽出WHERE条件と更新SET内容の関係に着目して記述します。
午後記述で使える加点キーワード（クリックでコピー）
この用語が出題された過去問を解く（1分演習）
即時アウトプットで定着データベーススペシャリスト 過去問演習で実践力を鍛える
