QA@IT
«回答へ戻る

40
 すくなくともREAD_COMMITTED_SNAPSHOTでの動作はORACLEのデフォルトと極めて近い動作をするはずですが
 あくまでミドル層やクライアントによる動作の影響は考慮しない範囲で、ですが
 
+分離レベルは他のトランザクションとの同時実行性を考慮して決めるものです
+スナップショット分離レベル一択と言った単純な話ではありません
+
+他のトランザクションを待たせて良いのなら、SERIALIZABLEで実行すれば良いだけの話です
+
+個人的には更新のあるトランザクションでスナップショット分離レベルは通常ありません(selectしたデータの更新が保証されないので)
+反復可能読み取りが必要で、どうしてもREPEATABLE READで実行できないときには選択肢の一つとしてはありますが

クライアントやミドル層を除いて、あくまでサーバの動作だけで見た場合

読み取り一貫性(行バージョン)が無かった。

行バージョンはスナップショットを実現するための内部機構です
昔のSQL Serverにはスナップショットはなかったので、まあ正しいと言ってもいいと思います

トランザクション単位で共有ロックをかける

トランザクション単位でという意味は不明ですが、違います
スナップショットでのselectはデフォルトではロックをかけません
READ_COMMITTED_SNAPSHOTでもスナップショット分離レベルでも同様です
ORACLEでのFOR UPDATEなしのselectに相当です

読み取り一貫性(行バージョン)はトランザクション単位で、挿入・更新・削除も有り

読み取り一貫性は、更新、削除を保証しません
READ_COMMITTED_SNAPSHOTはトランザクション単位の読み取り一貫性は保障しません

読み取り一貫性(行バージョン)が行単位の(本当のOracleと同じ)分離レベルは無い。

行単位の意味がわかりません
一貫性とは複数の間で整合性が取れている事ですよ
テーブルに対して全ての行に一貫性があるとか
トランザクションに対して全ての文で一貫性があるとか

本当のORACLEとまったく同じ動作を求めるなら、ORACLEを使うしかありませんが
すくなくともREAD_COMMITTED_SNAPSHOTでの動作はORACLEのデフォルトと極めて近い動作をするはずですが
あくまでミドル層やクライアントによる動作の影響は考慮しない範囲で、ですが

分離レベルは他のトランザクションとの同時実行性を考慮して決めるものです
スナップショット分離レベル一択と言った単純な話ではありません

他のトランザクションを待たせて良いのなら、SERIALIZABLEで実行すれば良いだけの話です

個人的には更新のあるトランザクションでスナップショット分離レベルは通常ありません(selectしたデータの更新が保証されないので)
反復可能読み取りが必要で、どうしてもREPEATABLE READで実行できないときには選択肢の一つとしてはありますが

クライアントやミドル層を除いて、あくまでサーバの動作だけで見た場合

>読み取り一貫性(行バージョン)が無かった。

行バージョンはスナップショットを実現するための内部機構です
昔のSQL Serverにはスナップショットはなかったので、まあ正しいと言ってもいいと思います


>トランザクション単位で共有ロックをかける

トランザクション単位でという意味は不明ですが、違います
スナップショットでのselectはデフォルトではロックをかけません
READ_COMMITTED_SNAPSHOTでもスナップショット分離レベルでも同様です
ORACLEでのFOR UPDATEなしのselectに相当です


>読み取り一貫性(行バージョン)はトランザクション単位で、挿入・更新・削除も有り

読み取り一貫性は、更新、削除を保証しません
READ_COMMITTED_SNAPSHOTはトランザクション単位の読み取り一貫性は保障しません


>読み取り一貫性(行バージョン)が行単位の(本当のOracleと同じ)分離レベルは無い。

行単位の意味がわかりません
一貫性とは複数の間で整合性が取れている事ですよ
テーブルに対して全ての行に一貫性があるとか
トランザクションに対して全ての文で一貫性があるとか

本当のORACLEとまったく同じ動作を求めるなら、ORACLEを使うしかありませんが
すくなくともREAD_COMMITTED_SNAPSHOTでの動作はORACLEのデフォルトと極めて近い動作をするはずですが
あくまでミドル層やクライアントによる動作の影響は考慮しない範囲で、ですが

分離レベルは他のトランザクションとの同時実行性を考慮して決めるものです
スナップショット分離レベル一択と言った単純な話ではありません

他のトランザクションを待たせて良いのなら、SERIALIZABLEで実行すれば良いだけの話です

個人的には更新のあるトランザクションでスナップショット分離レベルは通常ありません(selectしたデータの更新が保証されないので)
反復可能読み取りが必要で、どうしてもREPEATABLE READで実行できないときには選択肢の一つとしてはありますが

回答を投稿

クライアントやミドル層を除いて、あくまでサーバの動作だけで見た場合

読み取り一貫性(行バージョン)が無かった。

行バージョンはスナップショットを実現するための内部機構です
昔のSQL Serverにはスナップショットはなかったので、まあ正しいと言ってもいいと思います

トランザクション単位で共有ロックをかける

トランザクション単位でという意味は不明ですが、違います
スナップショットでのselectはデフォルトではロックをかけません
READ_COMMITTED_SNAPSHOTでもスナップショット分離レベルでも同様です
ORACLEでのFOR UPDATEなしのselectに相当です

読み取り一貫性(行バージョン)はトランザクション単位で、挿入・更新・削除も有り

読み取り一貫性は、更新、削除を保証しません
READ_COMMITTED_SNAPSHOTはトランザクション単位の読み取り一貫性は保障しません

読み取り一貫性(行バージョン)が行単位の(本当のOracleと同じ)分離レベルは無い。

行単位の意味がわかりません
一貫性とは複数の間で整合性が取れている事ですよ
テーブルに対して全ての行に一貫性があるとか
トランザクションに対して全ての文で一貫性があるとか

本当のORACLEとまったく同じ動作を求めるなら、ORACLEを使うしかありませんが
すくなくともREAD_COMMITTED_SNAPSHOTでの動作はORACLEのデフォルトと極めて近い動作をするはずですが
あくまでミドル層やクライアントによる動作の影響は考慮しない範囲で、ですが

クライアントやミドル層を除いて、あくまでサーバの動作だけで見た場合

>読み取り一貫性(行バージョン)が無かった。

行バージョンはスナップショットを実現するための内部機構です
昔のSQL Serverにはスナップショットはなかったので、まあ正しいと言ってもいいと思います


>トランザクション単位で共有ロックをかける

トランザクション単位でという意味は不明ですが、違います
スナップショットでのselectはデフォルトではロックをかけません
READ_COMMITTED_SNAPSHOTでもスナップショット分離レベルでも同様です
ORACLEでのFOR UPDATEなしのselectに相当です


>読み取り一貫性(行バージョン)はトランザクション単位で、挿入・更新・削除も有り

読み取り一貫性は、更新、削除を保証しません
READ_COMMITTED_SNAPSHOTはトランザクション単位の読み取り一貫性は保障しません


>読み取り一貫性(行バージョン)が行単位の(本当のOracleと同じ)分離レベルは無い。

行単位の意味がわかりません
一貫性とは複数の間で整合性が取れている事ですよ
テーブルに対して全ての行に一貫性があるとか
トランザクションに対して全ての文で一貫性があるとか

本当のORACLEとまったく同じ動作を求めるなら、ORACLEを使うしかありませんが
すくなくともREAD_COMMITTED_SNAPSHOTでの動作はORACLEのデフォルトと極めて近い動作をするはずですが
あくまでミドル層やクライアントによる動作の影響は考慮しない範囲で、ですが