2

SQLスクリプトが与えられた場合：

  1. トランザクションを開始します。サーバーXから開始されます
  2. テーブルAからテーブルB（=新しいテーブル）へのクエリからselectintoを実行します
  3. テーブルAをテーブルC（=新しいテーブル）に選択します
  4. 専念。

エラーは発生しません。すべてが1台のサーバーで行われるため、これはまだ分散トランザクションではありません。

ここで、3。になるとしましょう。

  1. テーブルAをテーブルCに選択しますが、テーブルCは別のサーバー上にあります（EXECUTE('SELECT * INTO ...') AT [remoteserver]FROM句では3つのプレフィックス構文が許可されていますが、INTO句では許可されていないため、これを行う必要があります）

これで、SQL Serverは、このステートメント（3）が（現在分散されている）トランザクションで別のステートメントとの競合を生成することを通知します。

エラーの原因を示し、分散トランザクションが実際に私のセットアップで機能することを証明するために、ステップ2）をコメントアウトします。

これですべてが機能します。したがって、ステップ2）で問題が発生します。ただし、ステップ2）は基本的に、テーブルAと他のいくつかのテーブルで結合選択を実行してテーブルBを生成するだけで、他には何も実行しません。

その場合（分散トランザクションバージョンの場合）、ステップ3）を問題なく実行できないのに、同じ非分散トランザクションバージョンが問題なく機能するのはなぜですか？そして、どのような対立が起こり得るのでしょうか？

4

2 に答える 2

0

クエリ2とクエリ3には互換性がないようです。理由を理解するには、各クエリの原因となるロックを調べてください。そのための1つの方法は次のとおりです。

  1. トランザクションを開始します
  2. クエリ2（または3）を実行します
  3. ロックはビューにありますsys.dm_tran_locks。
  4. ロールバックまたはコミット、関係ありません

おそらく、結果のロックを質問に追加できますか？

于 2012-08-18T18:37:14.607 に答える
0

OKみんな。問題を見つけて、それは面白いです。それは別のものでした。問題とは何の関係もないと思ったので、テーブルAも作成したことについては触れませんでした。

手順2）を次のように置き換えます

2) Create Table A **with** a primary key.

これで、非分散バージョンは機能しますが、分散バージョンは機能しません（つまり、ステップ3）。

手順2）を次のように置き換えます

2) Create Table A with **no** primary key

これで、両方のバージョンが正常に機能します。

しかし、トランザクションの前のどこかに主キーを使用してテーブルを作成するときにもすべてが機能するため、私はあまり気にしません。トランザクションでcreatetableステートメントを使用して主キーを作成すると、3）分散バージョンが機能しなくなります。

誰かが理由を知っているなら、ここに書いてください:)

于 2012-08-18T18:55:47.803 に答える