卸載批次處理
某些應用程式要求對資料執行大量處理的批次作業。在許多情況下，這些批次作業無法在線上交易處理 (OLTP) 伺服器上執行，因為處理負擔會影響伺服器上的其他作業。在此情況下，必須在個別伺服器上執行批次處理。有時，批次處理僅為卸載；而有時，批次處理的結果會傳播回線上處理伺服器。
下圖顯示將資料複寫至批次處理伺服器的一般狀況：
.gif "正在複寫要批次處理的資料")
Adventure Works 循環範例
Adventure Works Cycles 是虛構的製造公司，用於示範資料庫概念與案例。如需詳細資訊，請參閱＜AdventureWorks2008R2 範例資料庫＞。
Adventure Works Cycles 使用批次處理來檢查其網站上是否有信用卡詐欺。從網站交易收集的資料將從維護網站的 Microsoft SQL Server 複寫至用於多個 Adventure Works Cycles 應用程式的個別 SQL Server。在批次處理伺服器上，對資料進行檢查，查找是否有信用卡詐欺的情況。儘管偵測詐欺時產生的資料量很少 (如果顯示帳戶有可疑活動，便會更新少數幾個資料行中的資料)，但檢查需要進行大量計算且需要大量的伺服器資源。在執行批次處理後，少量資料將傳送回網站的 OLTP 伺服器，以指示任何可能有詐欺跡象的帳戶。
這個狀況的一般需求
批次處理應用程式通常具有下列要求，適當的複寫方案必須提出因應對策：
系統必須維護交易一致性。
系統應具有低度延遲：在線上處理伺服器上所作的更新必須能快速傳送到批次處理伺服器。
系統應有高度輸送量：應處理大量交易的複寫。
複寫處理在線上處理伺服器上需要最低負擔。
資料變更可雙向流動：批次處理的結果可傳播回線上處理伺服器。
批次處理伺服器端所需的資料可以是線上處理伺服器端可用資料的子集。
這個狀況要使用的複寫類型
SQL Server 使用的是出版業的字眼，來描述複寫系統的元件。元件包含發行者、訂閱者、發行集與發行項，以及訂閱。
在以上圖表中，線上處理伺服器為發行者。線上處理伺服器上某些或所有資料包含在發行集中，每個資料表則是一個發行項 (發行項也可以是其他資料庫物件，例如預存程序)。批次處理伺服器是發行集的「訂閱者」，並以訂閱的方式接受結構描述和資料。
如果將結果傳播回線上處理伺服器，則批次處理伺服器也是「發行者」(通常具有和線上處理伺服器上相同的發行集)，且線上處理伺服器訂閱至此發行集。
如需系統元件的詳細資訊，請參閱＜複寫發行模型概觀＞。
SQL Server 為不同的應用程式需求提供不同類型的複寫：快照式複寫、交易式複寫，以及合併式複寫。此狀況很符合處理前一章節所列出的需求大綱，最適合實作交易式複寫。如需交易式複寫的資訊，請參閱＜交易式複寫概觀＞以及＜交易式複寫的運作方式＞。
依設計，交易式複寫可解決此狀況的主體需求：
交易一致性
低度延遲
高度輸送量
最低負擔
此狀況下要考慮的選項有篩選、點對點交易式複寫和雙向交易式複寫：
實作這個狀況的步驟
若要實作這個狀況，您必須先建立發行集與訂閱，然後初始化每個訂閱。按一下下列的連結，以取得有關每個步驟的詳細資訊：
SQL Server Management Studio: 如何：設定點對點交易式複寫 (SQL Server Management Studio)
複寫 Transact-SQL 程式設計：如何：設定點對點交易式複寫 (複寫 Transact-SQL 程式設計)
在初始化訂閱，而且資料在發行者與訂閱者之間流動之後，您可能需要參考下列主題，以取得一般管理與監視工作的資訊：