2012-04-02 8 views

答えて

2

Oracleは、MVCCを使用してデータベースのデータへのアクセスを制御します。

InformixとDB2(他のDBMSの間で)は、ほとんどの場合、ロックを使用します。

テーブルをロックする文があります。

LOCK TABLE tablename IN { SHARE | EXCLUSIVE } MODE; 

データベースがログに記録されていない場合は、あなたがテーブルのロックを解除することができます:あなたのデータベースがログに記録されている場合

UNLOCK TABLE tablename; 

(事務の正常な状態)、トランザクション内でのみ表をロックすることができ、トランザクションがコミットまたはロールバックされたときにロックが解放されます。

さらに、FOR UPDATE句を持つカーソルは、行にロックを適用します。更新ロック(行が変更されるため)は常にトランザクションの最後まで続きますが、読み取りロックの期間は分離レベルに依存するため、分離レベルについて知る必要があります。

実際、REPEATABLE READ(別名SERIALIZABLE —)には、Informixの分離レベルと標準分離レベルの背後にある複雑なストーリーがあります。すべてのステートメントは処理された行にロックを適用します。行が処理されました。これは分離を確実にするために必要です。

+0

私はあなたの言うことを理解していますが、行や表をブロックするのではなく、プロセスをブロックすることには興味がありません。 (存在しない場合)PK(外部から生成された)を挿入し、存在する場合にカウントを更新する、長期間保存されたストアドプロシージャを用意しておきましょう。そのSPへの2つのコールが同時に発生した場合、どちらもPKを挿入しようとするために失敗します。 PL/SQLでは、セマフォを使用して相互排除を保証できます(dbms_lock.acquireを使用)。可能ならばInformixでも同じことをしたいと思います。 – Samuel

+1

正しい制約が設定されていれば(重複する値は許可されません)、2つのプロシージャのうち1つだけが所定のPK値を挿入できます。 DBMSはそれを自動的に担当します。 SPL(ストアドプロシージャ言語)には、挿入の失敗から回復するために使用できる例外メカニズムがあります。あなたが説明するようにロックを追加することに大きな利点があるかどうかはわかりません。それらはシステムに組み込まれていませんが、本当にそうしたいと思うのであればかなり簡単にシミュレートできますが、私はそれには(コードを変更しない以外の)利点があるかどうかまだ分かりません。 –

+0

Oracle DBMS_LOCKに関する1つの記事は、Oracleで必要な理由の1つは、1つのセッションで別のセッションの更新が見えないということです。これは、Informixやその他のロックベースのDBMSでは問題ではありません。隔離レベルの影響を受けて、セッションは他のセッションによってコミットされた後、別のセッションの変更を見ることができます。私は、Informixで解決すべき問題があるかどうかを調べるために、あなたがやっていることの詳細な例と、Oracleでロックが必要な理由を調べる必要があります。私はInformixにそれらが必要であるとは確信していません。 –