更新時のロック

データベース・サーバは次の手順を使用して特定のレコードに含まれる情報を修正します。挿入時と同様に、独立性レベルに関係なくすべてのトランザクションで次の操作手順が発生します。

テーブルで共有スキーマ・ロックを保持していない場合は、取得します。
テーブルで書き込みを意図したテーブル・ロックを保持していない場合は、取得します。
1. 更新の候補となるローを識別します。ローがスキャンされている間は、ローはロックされます。デフォルトのロック動作については、独立性レベルと一貫性を参照してください。
  
  独立性レベル 2 と 3 では、デフォルトのロック動作とは異なる次のような違いが発生します。読み込みロックではなく書き込みを意図したローレベルのロックが取得されます。また、書き込みを意図したロックは、更新の候補としては最終的には拒否されたローで取得される場合があります。
2. 手順 2.a で識別された候補となる各ローは、残りのシーケンスに従います。
影響を受けるローに書き込みロックをかけます。
UPDATE 文により、影響を受けるそれぞれのカラムの値を更新します。
インデックス付きの値を変更した場合は、新しいインデックス・エントリを追加します。ローの元のインデックス・エントリは残りますが、削除済みのマークが付けられます。短期間の挿入ロックが保持されている間に、新しい値の新しいインデックス・エントリが挿入されます。サーバは、必要に応じてインデックスのユニーク性を検証します。
ローの外部キー値が変更された場合、プライマリ・テーブルで共有スキーマ・ロックを取得し、挿入時のロックの説明に従って、新しい外部キー値を挿入します。同様に、必要に応じて wait_for_commit の手順に従います。
テーブルが参照整合性関係においてプライマリ・テーブルであり、かつ関係の UPDATE アクションが RESTRICT でない場合、外部テーブル (間) で共有スキーマ・ロックを、各外部テーブルで書き込みを意図したテーブル・ロックをそれぞれ取得することで、外部テーブル内で影響のあるローを特定し、次に影響のあるすべてのローで書き込みロックを取得して、必要に応じてそれぞれのローを修正します。このプロセスは、参照整合性制約のネストした階層でカスケードされることがあります。

最後の手順の後で、AFTER UPDATE トリガが起動する場合があります。COMMIT の実行時、サーバはこのトランザクションで生成されたオーファンの数が 0 であることを確認することで参照整合性を検証し、次にすべてのロックを解放します。

カラムの値を変更するために、多くの操作が必要になることがあります。データベース・サーバが実行する作業量は、修正するカラムがプライマリ・キーまたは外部キーの一部でない場合は大幅に少なくなります。カラムをユニークと宣言したために、変更する値が明示的または暗黙的にインデックスに含まれていない場合も作業量は少なくて済みます。

UPDATE オペレーション中に参照整合性を確認するオペレーションは、INSERT 中に確認する場合よりも複雑になります。実際、プライマリ・キーの値を変更すると、オーファンが作成されることがあります。置換値を挿入すると、データベース・サーバはもう一度オーファンをチェックしなければなりません。