読み取り一貫性の実現方法の違い

Oracle Serverでは、通常のSELECTではロックがかかりません（SELECT FOR UPDATEは除く）。トランザクション途中のデータを他のユーザーがSELECTした場合、UNDOセグメントにある変更前のコミット済みデータを読み込み、読み取り一貫性を保証します。一方、SQL Serverでは、UNDOセグメントに相当するものはありません。読み取り一貫性は、ロックメカニズムを使用して実現します。

ロックがかけられているデータに対してSELECT文を実行した場合の動作は、それぞれ下の図のとおりです。

■ 図1 ：Oracle Serverの場合

■ 図2 ：SQL Serverの場合

SQL Serverでは、次に紹介するロックを使用して、読み取り一貫性を実現します。

ロックの種類

Oracle Serverの主なロックは、「共有ロック」と「排他ロック」の2種類です。一方、SQL Serverの主なロックは、次の表に示す3種類です。ロックの互換性とは、ロックを同時にかけられるかどうかということです。

●共有ロックと排他ロック
上記【図2】の例で、Aさんが「ぷちっとプリン」のデータを更新した場合、UPDATEステートメントを実行すると排他ロックがかかり、それはトランザクション終了時まで保持されます。そのデータをBさんがSELECTすると共有ロックがかけられますが、共有ロックと排他ロックは互換性がないので、Bさんは待つことになります。

●更新ロックの使用
Oracle Serverでいう「SELECT〜FOR UPDATE」のような使い方です。SELECTしてから更新するような場合に発生するデッドロックを防ぐために、ロックヒントのUPDLOCKを指定して使用します。このロックは更新の直前に排他ロックに変わり、トランザクション終了時まで保持されます。

ロックの制御

SQL Serverでは、実行したSQLステートメントによって自動的に最適なロックが選択されますが、次の方法で制御することもできます。

セッション レベル

● SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED ：SELECT時にロックがかからない READ COMMITTED（既定） ：SELECT時にロックがかかる

テーブル レベル

● FROM テーブル名 WITH ロックヒント NOLOCK ：ロックがかからない ROWLOCK ：行レベルでロックがかかる TABLOCK ：表レベルでロックがかかる UPDLOCK ：更新ロックがかかる

ロック タイムアウト

● SET LOCK_TIMEOUT 経過時間 1（既定） ：無制限に待つ 0 ：待ち時間なし。ロックがかかっているとすぐにエラーが返される N ：経過時間をミリ秒で指定。経過時間を過ぎるとエラーが返される

まとめ 〜SELECT時の注意点〜

SQL Serverでは、SELECTでも『待ち』が発生する可能性があります。更新する側でもトランザクションを短くするなどの工夫が必要ですが、SELECTする側でも「ロック タイムアウトを指定する」、「WHERE句で条件を絞り、必要なデータのみ読込む」など、不要な『待ち』を防ぐための注意が必要です。