使用條件式刪除追蹤來提升合併複寫效能

適用於:SQL Server

附註

SQL Server 的未來版本將移除此功能。 請避免在新的開發工作中使用這項功能,並規劃修改目前使用這項功能的應用程式。

透過合併複製,你可以指定複製觸發器和系統資料表不會追蹤一個或多個條目的刪除。 如果你選擇此選項,刪除不會被追蹤或複製,無論是 Publisher 還是任何訂閱者。 此選項支援多種應用場景,並在不需或不希望複製刪除的情況下,提供效能優化。 效能提升有三方面:系統不會儲存刪除的元資料;同步時不會列舉刪除;以及不會將刪除複製給或套用於訂閱者。

附註

若要使用僅限下載發行項,發行集的相容性層級必須至少為 90RTM。

此選項可在建立發行時指定;如果應用程式需要複寫某些刪除作業,而不複寫其他刪除作業(例如批次刪除),也可以將此選項切換為開啟或關閉。 以下範例說明此選項在應用程式中可能的用法:

  • 行動銷售團隊所使用的應用程式一般都具有資料表,例如 SalesOrderHeader、 SalesOrderDetail 和 Product。 訂單會先在「訂閱者」端輸入,然後複寫到「發行者」端,而「發行者」通常會將資料提供給訂單履行系統。 許多行動工作者使用含有限儲存的手持式裝置:訂單在「發行者」端接收後,可以在「訂閱者」端刪除。 由於此訂單在系統中仍處於有效狀態,因此刪除作業不會同步到 Publisher。

    在此狀況下,不會追蹤 SalesOrderHeader 和 SalesOrderDetail 資料表的刪除。 Product 資料表的刪除作業會被追蹤,因為如果產品在「發行者」端被刪除,該刪除操作就應傳送給「訂閱者」,以保持產品清單為最新。

  • 應用程式可以將記錄資料儲存在資料表 (例如 TransactionHistory,它會定期清除一年前的舊記錄) 中。 資料表可以使用篩選,以便「訂閱者」僅接收當月的交易資料。 儘管「發行者」端每月進行的批次刪除 (即清除舊資料) 與「訂閱者」無關,但依預設它們仍會被追蹤及列舉。

    在此狀況下,可以在批次處理前停止系統中的作業,並讓應用程式停用對刪除的追蹤。 處理完成後,追蹤可再次啟用。

重要

如果發行者端仍有其他活動在進行,您必須確保在刪除追蹤停用期間,不會發生任何應傳播至訂閱者的刪除作業。

若要指定刪除不被追蹤