在什麼情況下，SQL複製部分地（並且默默地）從c＃應用程序的MSDTC事務中失敗

Question

我們有一個特別奇怪的問題;讓我設置場景。 發現的解決方案見下文

我們有三個SQL Server 2005個數據庫，爲參數的緣故叫：阿爾法，測試版和伽瑪。

有這些數據庫之間定義複製關係如下：

這三個數據庫都有一個名爲「演示。」具有相同的架構表。複製已建立，以便Alpha是提供程序，其他兩個數據庫是訂戶。

1. 使用MSDTC交易（由一個TransactionScope處理）甲C＃.NET 3.5應用程序是讀取和寫入到數據庫：α和β。
2. 此交易中的表「AnExample」僅在Alpha上進行更新。
3. MSDTC事務成功提交。
4. 「演示。」表可能是更新阿爾法和變化會立即複製到伽瑪
5. 上測試版（探查證實，沒有活動發生在數據庫上），也不是任何錯誤不發生變化在SQL日誌或事件日誌
6. 重新運行Management Studio中更新「演示。」有相同的憑證相同的查詢成功（複製測試版發生）
7. 運行MSDTC事務寫入另一個表提出在Beta版，然後使用主要應用DAL，連接字符串和配置的測試應用程序阿爾法的「演示。」表完全相同的寫操作也完全成功（複製到測試版發生）

這有使我們相信主應用程序中發生的變化並不是孤立的。

可能的線索/紅鯡魚

我們可以在我們的試驗成功，並且主要應用程序使用的是隔離級別莫名其妙地改變了實際查詢之間看到的唯一區別。在成功查詢時，它將事務隔離級別設置爲僅讀取提交，而在失敗場景中將其設置爲可序列化（儘管沒有顯式調用來更改代碼庫或存儲過程中的隔離級別）。

我們確實認爲這是一種紅鯡魚，因爲在Management Studio中使用此隔離級別運行查詢後，問題再次成功。但是，這可能是我們尚未發現的另一個問題的症狀，這是不同的觀點。

爲了完整起見，此處查詢的設置無法複製到Beta（但對Gamma有影響）。

-- 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

所以我們發現了什麼似乎是問題。如上所述;我們有一個分佈式交易，寫入Alpha然後Beta。然後寫入Beta然後成功複製到Gamma它默默地失敗到Alpha。然而有一個遺漏，其中一個寫入的Alpha實際上被複制到Beta（大數據庫模式的麻煩）。將此寫入移動到Beta意味着突然複製成功。

我還沒有看到它記錄，通過分佈式事務更新不能複製更多的一種方式，但公平這是一個有點晦澀的問題，簡單地解決了確保所有寫入複製表發生在同一個數據庫。

希望這可以幫助別人。