どのような状況では、SQLレプリケーションはC＃アプリケーションのMSDTCトランザクションから部分的に（そしてサイレントに）失敗するでしょう

Question

特に奇妙な問題があります。シーンを設定しましょう。 アルファ、ベータとガンマ：ソリューションと呼ばれる引数のために、我々は3つのSQL Server 2005件のデータベースを持っている

下記参照ました。

次のようにこれらのデータベース間で定義されたレプリケーションの関係があります：

すべての3つのデータベースが同じスキーマを持つ「AnExample」という名前のテーブルを持っています。 アルファがプロバイダであり、他の2つのデータベースがサブスクライバであるようにレプリケーションが設定されています。

1. MSDTCトランザクション（TransactionScopeによって処理される）を使用するC＃.Net 3.5アプリケーションは、AlphaとBetaの両方のデータベースに対する読み書きです。
2. このトランザクション内のテーブル「AnExample」は、Alpha上でのみ更新されています。
3. MSDTCトランザクションが正常にコミットされます。
4. 「AnExample」テーブルは、おそらくアルファに更新され、変更はすぐに変更なしベータ、また任意のエラーです（プロファイラは何の活動がデータベースに起こらないことを確認）に発生していないガンマ
5. に複製されます別のテーブルにMSDTCトランザクションの書き込みを実行するSQLログやイベントログ（ベータ版が発生し、レプリケーションに）
6. 再実行しているのと同じ資格情報を使用してManagement Studioで「AnExample」を更新同じクエリが成功した
7. に引き上げベータに、メインアプリケーションのDAL、接続文字列、およびコンフィギュレーションを使用してテストアプリケーションとアルファの「AnExample」テーブルに、その後まったく同じ書き込みも完全にこれは持っている

（複製ベータ版にが発生した）成功します孤立して起こっていない主なアプリケーションに何らかの変化が起こっていると私たちに信じさせました。

可能な手がかり/赤ニシン

我々は成功したテストとメインアプリケーションが使用している実際のクエリの間で見ることができる唯一の違いは、分離レベルが何らかの形で変更されたことです。成功したクエリでは、（トランザクションベースの分離レベルをコードベースまたはストアドプロシージャに変更するための明示的な呼び出しがないにもかかわらず）失敗したシナリオでは、シリアライズ可能に設定されています。

Management Studioでこの分離レベルでクエリを実行すると、問題なく問題なく成功するため、これは多少の赤みを帯びていると感じます。しかし、これは、これがまだ発見していない別の問題の症状かもしれないという点が異なるという事実。

ここでは、ベータ版への複製に失敗したクエリの設定について説明します（ただし、ガンマに適用されます）。

-- network protocol: TCP/IP 
set quoted_identifier on 
set arithabort off 
set numeric_roundabort off 
set ansi_warnings on 
set ansi_padding on 
set ansi_nulls on 
set concat_null_yields_null on 
set cursor_close_on_commit off 
set implicit_transactions off 
set language us_english 
set dateformat mdy 
set datefirst 7 
set transaction isolation level *serializable* 

これはちょっとしたヘッドスケーターです。

Answer 1

これはトランザクションレプリケーションと見なされますか？ そうであれば、購読者へのプッシュの変更はログリーダーによってトランザクションログから収穫されるため、問題は本当に奇妙に聞こえます。

パブリッシャのデータベースでトレースを実行しようとすると、レプリケーションエージェントが何をしているかを見ることができます。何が間違っているのかはっきりしませんが、何かがあなたに飛び出すでしょう。

Answer 2

私たちは問題があるように見えました。上記のように; アルファに、次にベータに書き込みを行う分散トランザクションがあります。 ベータへの書き込みは、その後、Gammaに正常に複製され、それはサイレントモードで失敗します。アルファ。しかし、アルファへの書き込みの1つが実際にベータ版（大規模なデータベーススキーマの問題）に複製されているという1つの省略がありました。この書き込みをベータに移動すると、突然複製が成功しました。

分散トランザクションによる更新がそれ以上の方法では複製できないことはわかりませんでしたが、公平であることは、レプリケートされたテーブルのすべての書き込みが同じデータベースで行われたことを保証することによって単純に解決されました。

これは他の人に役立つことを願っています。