維護和疑難解答 BizTalk Server 資料庫

本文提供如何維護和疑難解答 BizTalk Server 資料庫的詳細資訊。

原始產品版本：BizTalk Server 資料庫
原始 KB 編號： 952555

摘要

對於成功的 BizTalk Server 訊息環境而言，Microsoft BizTalk Server 資料庫的健康情況很重要。 本文討論使用 BizTalk Server 資料庫時要考慮的重要事項。 這些考慮包括：

• 您必須停auto update statistics用 和 auto create statistics SQL Server 選項。
• 您必須正確設定 max degree of parallelism (MAXDOP) 選項。
• 判斷何時可以重建索引 BizTalk Server。
• 可能會發生鎖定、死結或封鎖。
• 您可能會遇到大型資料庫或數據表的問題。
• BizTalk SQL Server Agent 作業。
• 服務實例可能會暫停。
• 您可能會遇到 SQL Server 和 BizTalk Server 效能問題。
• 您應該遵循 BizTalk Server 中的最佳做法。

簡介

本文說明如何維護 BizTalk Server 資料庫，以及如何針對 BizTalk Server 資料庫問題進行疑難解答。

您必須停用自動建立統計數據和自動更新統計數據選項

您必須讓 資料庫上的 auto create statisticsBizTalkMsgBoxDb 和 auto update statistics 選項保持停用。 若要判斷是否停用這些設定，請在 SQL Server 中執行下列預存程式：

EXEC sp_dboption 'BizTalkMsgBoxDB', 'auto create statistics'
EXEC sp_dboption 'BizTalkMsgBoxDB', 'auto update statistics'

您應該將目前的設定設為 off。 如果此設定設為 on，請在 SQL Server 中執行下列預存程式來關閉它：

EXEC sp_dboption 'BizTalkMsgBoxDB', 'auto create statistics', 'off'
EXEC sp_dboption 'BizTalkMsgBoxDB', 'auto update statistics', 'off'

您必須正確設定 Max Degree of Parallelism 屬性

在執行 SQL Server 並裝載BizTalkMsgBoxDb資料庫的計算機上，將平行處理原則run_value和config_value屬性的最大程度設定為1值。 在更新的 SQL 版本中，也可以為每個資料庫指定此設定，而不是針對每個 SQL 實例指定。 如需詳細資訊，請 參閱設定 MAXDOP。 若要判斷max degree of parallelism設定，請針對 SQL Server 中的 Master 資料庫執行下列預存程式：

EXEC sp_configure 'show advanced options', 1;
GO
EXEC sp_configure 'max degree of parallelism'

run_value如果和 config_value 屬性未設定為 1 值，請在 SQL Server 中執行下列預存程式，將它們設定為 1：

EXEC sp_configure 'show advanced options', 1;
GO
RECONFIGURE WITH OVERRIDE;
GO
EXEC sp_configure 'max degree of parallelism', 1;
GO
RECONFIGURE WITH OVERRIDE;
GO

判斷何時可以重建索引 BizTalk Server

大部分的 BizTalk Server 索引都是叢集 (索引標識碼：1) 。 您可以使用 SQL Server DBCC SHOWCONTIG 語句來顯示 BizTalk Server 數據表的片段資訊。

BizTalk Server 索引是以 GUID 為基礎。 因此，通常會發生片段。 如果語句傳DBCC SHOWCONTIG回的掃描密度值小於 30%，則可以在停機期間重建 BizTalk Server 索引。

許多 BizTalk Server 數據表都包含使用DataType定義的數據行。 無法在這些數據行中執行在線索引。 因此，您絕對不應該在 BizTalk Server 處理數據時重建 BizTalk Server 索引。

可能會發生鎖定、死結或封鎖

一般而言，鎖定和區塊會在 BizTalk Server 環境中發生。 不過，這些鎖定或區塊不會長時間保留。 因此，封鎖和死結表示潛在的問題。

您可能會遇到大型資料庫或數據表的問題

我們發現當資料庫較大時 BizTalkMsgBoxDb ，可能會發生效能問題。 在理想的情況下， BizTalkMsgBoxDb 資料庫不應該保存任何數據。 在 BizTalkMsgBoxDb 處理數據或移至 BizTalkDTADb 或 BAM 資料庫之前，應該將資料庫視為緩衝區。

在後端使用功能強大的 SQL Server 和許多長時間執行協調流程的環境，可能會有BizTalkMsgBoxDb大於 5 GB 的資料庫。 不使用長時間執行協調流程的高容量環境應該具有 BizTalkMsgBoxDb 小於 5 GB 的資料庫。

資料庫 BizTalkDTADb 沒有設定的大小。 不過，如果效能降低，資料庫可能太大。 對於某些客戶而言，20 GB 可能會被視為太大，而對於其他具有 200 GB 的客戶而言，在多個 CPU、大量記憶體以及快速網路和記憶體上執行的高度強式 SQL Server 可能可以正常運作。 當您有大型 BizTalk Server 資料庫時，可能會遇到下列問題：

• 資料庫 BizTalkMsgBoxDb 會持續成長。 不過，記錄檔和數據大小仍然很大。

• BizTalk Server 需要比平常更長的時間來處理簡單的訊息流程案例。

• BizTalk 管理控制台或健康情況與活動追蹤 (HAT) 查詢所花費的時間比平常長，而且可能會逾時。

• 資料庫記錄檔永遠不會被截斷。

• BizTalk SQL Server Agent 作業執行速度比平常慢。

• 相較於一般數據表大小，有些數據表較大或有太多數據列。

資料庫可能會因為各種原因而變大。 這些原因可能包括下列各項：

• BizTalk SQL Server Agent 作業未執行
• 大量暫止的實例
• 磁碟失敗
• 追蹤
• 節流
• SQL Server 效能
• 網路等待時間

請確定您知道環境中的預期內容，以判斷是否發生數據問題。

預設會在預設主機上啟用追蹤。 BizTalk 需要在單一主機上檢查 [允許主機追蹤] 選項。 啟用追蹤時，追蹤數據譯碼服務 (TDDS) 將追蹤事件數據從 BizTalkMsgBoxDb 資料庫移至 BizTalkDTADb 資料庫。 如果停止追蹤主機，TDDS 不會將數據移至 BizTalkDTADb 資料庫，而且 TrackingData_x_x 資料庫中 BizTalkMsgBoxDb 的數據表將會成長。

建議您將一部主機專用於追蹤。 若要允許 TDDS 在大量案例中維護新的追蹤事件，請建立單一追蹤主機的多個實例。 不應該有一個以上的追蹤主機存在。

數據表中可能會有太多數據列。 沒有設定的數據列數目太多。 此外，此數據列數目會因數據表中儲存的數據類型而有所不同。 例如，有超過1百萬個 dta_DebugTrace 數據列的數據表可能有太多數據列。 有 <HostName>Q_Suspended 超過 200,000 個數據列的數據表可能有太多數據列。

使用正確的 BizTalk SQL Server Agent 作業

BizTalk SQL Server Agent 作業對於管理 BizTalk Server 資料庫以及維護高效能非常重要。

備份 BizTalk Server SQL Server Agent 作業是在啟動 SQL Server Agent 和 BizTalkServer 主機實例時，唯一支援備份 BizTalk Server 資料庫的方法。 此作業需要所有 BizTalk Server 資料庫都使用完整恢復模式。 您應該為狀況良好的 BizTalk Server 環境設定此作業。 只有當 SQL Server Agent 停止，而且所有 BizTalk Server 主機實例都已停止時，才能使用 SQL Server 方法來備份 BizTalk Server 資料庫。

MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb SQL Server Agent 作業會無限地執行。 因此，SQL Server Agent 作業歷程記錄永遠不會顯示成功完成。 如果發生失敗，作業會在一分鐘內重新啟動，並繼續無限地執行。 因此，您可以放心地忽略失敗。 此外，可以清除作業歷程記錄。 只有在作業記錄報告此作業持續失敗並重新啟動時，才應該擔心。

MessageBox_Message_Cleanup_BizTalkMsgBoxDb SQL Server Agent 作業是唯一不應該啟用的 BizTalk Server 作業，因為它是由 MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb SQL Server Agent 作業啟動。

DTA 清除和封存 SQL Server Agent 作業可藉由清除和封存追蹤的訊息，協助維護BizTalkDTADb資料庫。 此作業會讀取數據表中的每個數據列，並比較時間戳來判斷是否應該移除記錄。

除了 SQL Server Agent 作業之外，MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb所有 BizTalk SQL Server Agent 作業都應該成功執行。

服務實例可能會暫停

服務實例可以暫停 (可繼續) 或暫停， (無法繼續) 。 這些服務實例可能是傳訊、協調流程或埠。

這些服務實例可能會讓 BizTalkMsgBoxDb 資料庫不必要地成長，而且可以終止。 您可以使用群組中樞來查詢、繼續或終止訊息。 您也可以使用 Terminate.vbs 腳本或 BHM 狀況監控 (BHM) 工具來查詢、清除及維護 BizTalk 資料庫。 在某些情況下，系統中可能會留下孤立或無訊息訊息。 BHM 工具可協助修正這些情況。

如需 Terminate.vbs 腳本的詳細資訊，請參閱 移除暫停的服務實例。

快取實例不會出現在 [ 群組中樞 ] 頁面中，而且您無法暫停或終止它們。 這項限制是數據表成長的常見原因。 若要在 2006 BizTalk Server 中防止快取服務實例出現新的廢止訊息，請在 Microsoft 知識庫文章936536中安裝 Hotfix。 此問題已在 BizTalk Server 2006 R2 和更新版本中修正。

如需廢止訊息的描述，請造訪下列 MSDN 網站： BizTalk Core 引擎的 WebLog

您可能會遇到 SQL Server 和 BizTalk Server 效能問題

BizTalk Server 會在一分鐘內 SQL Server 數百個簡短、快速的交易。 如果 SQL Server 無法維持此活動，BizTalk Server 可能會遇到效能問題。 在 效能監視器 中，監視 PhysicalDisk 性能物件中的 Avg. Disk sec/Read、Avg. Disk sec/Transfer 和 Avg. Disk sec/Write 效能監視器 計数器。 最佳值小於 10 毫秒 (毫秒) 。 20 毫秒或更大的值會被視為效能不佳。

• 針對 2005 SQL Server 效能問題進行疑難解答

• 為 BizTalk Server 資料庫提供高可用性

• 如何針對 SQL Server 效能問題進行疑難解答

BizTalk Server 中的最佳做法

在 SQL Server 上啟動 SQL Server Agent。 當 SQL Server Agent 停止時，無法執行負責資料庫維護的內建 BizTalk SQL Server Agent 作業。 此行為會導致資料庫成長，而此成長可能會造成效能問題。

將 SQL Server 記錄資料庫檔案 (LDF) 和主資料庫檔案 (MDF) 檔案放在不同的磁碟驅動器上。 當 和資料庫的LDF和MDF檔案BizTalkMsgBoxDbBizTalkDTADb位於相同的磁碟驅動器上時，可能會發生磁碟爭用。

如果您未受益於訊息本文追蹤，請勿啟用這項功能。 不過，在開發解決方案並進行疑難解答時啟用訊息本文追蹤是不錯的主意。 如果您這樣做，請確定您在完成時停用訊息本文追蹤。 啟用訊息本文追蹤時，BizTalk Server 資料庫會成長。 如果有需要啟用訊息本文追蹤的商務需求，請確認TrackedMessages_Copy_BizTalkMsgBoxDb和 DTA 清除和封存 SQL Server Agent 作業已順利執行。

一般而言，較小的事務歷史記錄會造成較佳的效能。 若要讓事務歷史記錄變小，請將備份 BizTalk Server SQL Server Agent 作業設定為更頻繁地執行。

資料庫 sp_ForceFullBackup 中的 BizTalkMgmtDb 預存程式也可用來協助執行數據和記錄檔的臨機操作完整備份。 預存程式會 adm_ForceFullBackup 以值 1 更新資料表。 下次執行備份 BizTalk Server 作業時，會建立完整的資料庫備份集。

BHM 狀況監控 (BHM) 工具可用來評估現有的 BizTalk Server 部署。 BHM 會執行許多資料庫相關檢查。

疑難排解

BizTalk Server SQL Server 資料庫的最佳疑難解答步驟取決於資料庫問題類型，例如封鎖或死結。 若要針對 BizTalk Server 資料庫問題進行疑難解答，請遵循下列步驟。

步驟 1：啟用並執行所有必要的 BizTalk SQL Server Agent 作業

除了MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb作業之外，所有 BizTalk SQL Server Agent 作業都應該啟用並成功執行。 請勿停用任何其他作業。

如果發生失敗，請使用 SQL Server 中的 [檢視歷程記錄] 選項來檢視錯誤資訊，然後據此針對失敗進行疑難解答。 請記住，MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDbSQL Server Agent 作業會無限地執行。 因此，您應該只在作業記錄報告作業持續失敗並重新啟動時才擔心。

步驟 2：使用 BHM 狀況監控 (BHM) /MsgBoxViewer 工具

在重現問題時收集 BHM 報告。

BHM 工具適用於疑難解答，因為它提供 HTML 報表，其中包含數據表大小和數據列計數的詳細資訊。 報告也可以協助判斷 BizTalk Server 是否節流。 此外，此工具會提供 BizTalk Server 資料庫和 BizTalk Server 組態的快照集檢視。

如需 BizTalk Server 節流的詳細資訊，請參閱如何 BizTalk Server 實作主機節流。

當 BizTalk Server 執行速度比平常慢時，請執行 BHM 工具，然後檢閱產生的 HTML 報告是否有任何問題。 [ 摘要] 區段會以黃色列出警告，並以紅色列出潛在問題。

此外，您可以使用 BHM 工具輸出來判斷哪些資料表最大且記錄最多。 下表列出通常成長最大的 BizTalk Server 數據表。 您可以使用此資料來判斷潛在問題可能存在的位置。

資料表	描述
<HostName>Q_Suspended	此數據表包含數據表中訊息的 Spool 參考，這些訊息與特定主機的暫止實例相關聯。 此數據表位於資料庫中 BizTalkMsgBoxDb 。
<HostName>Q	此數據表包含數據表中 Spool 與特定主機相關聯且未暫止之訊息的參考。 此數據表位於資料庫中 BizTalkMsgBoxDb 。
Spool Parts Fragments	這些數據表會將實際訊息數據儲存在資料庫中 BizTalkMsgBoxDb 。
Instances	此數據表會將所有實例及其目前的狀態儲存在資料庫中 BizTalkMsgBoxDb 。
TrackingData_0_x	這四個數據表會將商務活動監視儲存 (BAM) 追蹤到 TDDS 資料庫中 BizTalkMsgBoxDb 的事件，以將事件移至 BAMPrimaryImport 資料庫。
TrackingData_1_x	這四個數據表會將追蹤的事件儲存在資料庫中， BizTalkMsgBoxDb 以供 TDDS 將事件移至 BizTalkDTADB 資料庫。
Tracking_Fragmentsx Tracking_Partsx Tracking_Spoolx	其中兩個數據表都位於 BizTalkMsgBoxDb 和 BizTalkDTADb 資料庫中。 一個在在線，另一個離線。 在 BizTalk Server 2004 SP2 和更新版本中，TrackedMessages_Copy_BizTalkMsgBoxDbSQL Server Agent 作業會將追蹤的訊息本文直接移至資料庫中的BizTalkDTADb這些數據表。 在 BizTalk Server 2004 Service Pack 1 (SP1) 和舊版 BizTalk Server 2004 中，TrackedMessages_Copy_BizTalkMsgBoxDbSQL Server Agent 作業會將追蹤的訊息本文複製到資料庫中的這些數據表。BizTalkMsgBoxDb TrackingSpool_Cleanup_BizTalkMsgBoxDb SQL Server Agent 作業會清除離線數據表，使數據表上線，同時作業也會讓在線數據表脫機。
dta_ServiceInstances	此數據表會將服務實例的追蹤事件儲存在資料庫中 BizTalkDTADb 。 如果此數據表很大， BizTalkDTADb 則資料庫可能很大。
dta_DebugTrace	此數據表會將 Orchestration 調試程式事件儲存在 BizTalkDTADb 資料庫中。
dta_MessageInOutEvents	此數據表會將追蹤的事件訊息儲存在資料庫中 BizTalkDTADb 。 這些追蹤的事件訊息包括訊息內容資訊。
dta_ServiceInstanceExceptions	此數據表會儲存資料庫中 BizTalkDTADb 任何暫停服務實例的錯誤資訊。

請參考以下案例：

• <HostName>Q_Suspended 表

  如果數據 <HostName>Q_Suspended 表有許多記錄，數據表可能是出現在 群組中樞 或 HAT 中的有效暫止實例。 這些實例可以終止。 如果這些實例未出現在 群組中樞 或 HAT 中，則實例可能會快取實例或孤立路由失敗報告。 當暫停的實例終止時，會清除此數據表中的專案及其在 和 Instances 數據表中的Spool相關聯數據列。

  在此案例中，請繼續或終止暫止的實例，以處理這些實例。 您也可以使用 BHM 工具。

• <HostName>Q 表

  如果資料 <HostName>Q 表有許多記錄，可能存在下列類型的實例：

  • 可執行的實例
  • 使用中實例
  • 解除凍結的實例 BizTalk Server 需要時間來「趕上」並處理實例。

  當處理的傳入速率超過傳出處理速率時，這個數據表可能會成長。 當另一個問題發生時，例如大型BizTalkDTADb資料庫或 SQL Server 磁碟延遲時，可能會發生此案例。

• Spool、 Parts和 Fragments 資料表

  Spool如果 、 Parts和 Fragments 數據表有許多記錄，則許多訊息目前為作用中、解除凍結或暫停。 根據這些數據表中的大小、元件數目和片段設定，單一訊息可能會繁衍所有這些數據表。 每個訊息在數據表中 Spool 只有一個數據列，而且數據表中至少有一個數據 Parts 列。

• Instances 表

  BizTalk 系統管理員不應該允許許多暫止的實例保留在數據表中 Instances 。 只有在商業規則需要長時間執行的協調流程時，解除凍結的實例才應該保留。 請記住，一個服務實例可以與數據表上的 Spool 許多訊息相關聯。

• TrackingData_x_x 表

  如果數據 TrackingData_x_x 表很大，追蹤主機 (TDDS) 無法順利執行。 如果追蹤主機實例正在執行，請檢閱事件記錄檔和 TDDS_FailedTrackingData 資料庫中的數據表， BizTalkDTADb 以取得錯誤資訊。 如果 BizTalk 的節流狀態為 6 (大型資料庫) ，則如果不需要數據，也可以使用 BizTalk 終止符工具來截斷這些數據表。

  如果數據表和 BAMPrimaryImport 或TDDS_StreamStatusBizTalkDTADb數據表中的BizTalkMsgBoxDbTrackingData_x_x序號之間有很大的間距，則 TDDS 可能不會從BizTalkMsgBoxDb資料庫行動數據。 若要更正此問題，請使用 BHM 工具清除這些資料表並重設序號。

• dta_DebugTrace 和數據 dta_MessageInOutEvents 表

  在 dta_DebugTrace 協調流程上啟用 Shape開始和結束 時，會填入數據表。 如果數據 dta_DebugTrace 表有許多記錄，則會使用或正在使用這些協調流程偵錯事件。 如果一般作業不需要協調流程偵錯，請清除 Orchestration 屬性中的 [圖形開始和結束] 複選框。

  在 dta_MessageInOutEvents 協調流程和/或管線上啟用 訊息傳送和接收 時，就會填入數據表。 如果不需要這些追蹤事件，請在協調流程和/或管線屬性中清除此選項的複選框。

  如果停用這些追蹤事件，或資料庫中有 BizTalkMsgBoxDb 待處理專案，這些數據表可能會繼續成長，因為 TDDS 會繼續將此數據移至這些數據表。

  根據預設，會啟用全域追蹤。 如果不需要全域追蹤，則可以停用。 如需詳細資訊，請參閱 如何關閉全域追蹤。

  如果數據 dta_DebugTrace 表和/或 dta_messageInOutEvents 資料庫中的數據表太大，您可以在 BizTalkDTADb 停止追蹤主機之後手動截斷數據表。 BHM 工具也提供這項功能。

  若要截斷資料庫中 BizTalkMsgBoxDb 的所有追蹤數據表，請使用 BHM 工具。 BHM 工具可在 Microsoft 下載中心外部取得。

  如需追蹤資料庫大小指導方針的詳細資訊，請造訪下列 MSDN 網站： 追蹤資料庫大小調整指導方針。

• dta_ServiceInstanceExceptions 表

  在定期有暫止實例的環境中，數據 dta_ServiceInstanceExceptions 表通常會變大。

步驟 3：調查死結案例

在死結案例中，請在 SQL Server 上啟用 DBCC 追蹤，以便將死結資訊寫入 SQLERROR 記錄檔。

在 SQL Server 2005 和更新版本中，執行下列語句：

DBCC TRACEON (1222,-1)

在 SQL Server 2000 中，執行下列語句：

DBCC TRACEON (1204)

此外，使用 PSSDiag 公用程式來收集事件和 Lock:Deadlock Chain 事件的數據Lock:Deadlock。

資料庫 BizTalkMsgBoxDB 是 OLTP) 資料庫 (大量且高交易的在線事務處理。 預期會有一些死結，而此死結是由 BizTalk Server 引擎在內部處理。 發生此行為時，錯誤記錄檔中不會列出任何錯誤。 當您調查死結案例時，您在輸出中調查的死結必須與事件記錄檔中的死結錯誤相互關聯。

dequeue 命令和一些 SQL Server Agent 作業預期會死結。 一般而言，這些作業會選取為死結犧牲者。 這些作業會出現在死結追蹤中。 不過，事件記錄檔中不會列出任何錯誤。 因此，這是預期的死結，而且您可以放心地忽略這些作業的死結。

如果死結追蹤中經常出現死結，而且事件記錄檔中列出相互關聯的錯誤，您可能會想要死結。

步驟 4：尋找已封鎖的進程

使用 SQL Server 中的活動監視器，取得鎖定系統進程的SPID) (伺服器進程標識碼。 然後，執行 SQL Profiler 來判斷在鎖定 SPID 中執行的 SQL 語句。

若要針對 SQL Server 中的鎖定和封鎖問題進行疑難解答，請使用 PSSDiag for SQL 公用程式來擷取已啟用封鎖腳本的所有 Transact-SQL 事件。

在 SQL Server 2005 和更新版本中，您可以指定封鎖的進程閾值設定，以判斷哪些 SPID 或 SPID 封鎖的時間超過您指定的臨界值。

如需 封鎖進程閾值 設定的詳細資訊，請參閱 封鎖的進程閾值伺服器組態選項。

步驟 5：安裝最新的 BizTalk Server Service Pack 和累積更新

BizTalk Server 更新版本已移至累積更新 (CU) 模型。 累積更新將包含最新的修正程式。

刪除所有數據

如果資料庫太大或慣用的方法是刪除所有數據，則可以刪除所有數據。

BizTalkMsgBoxDb 資料庫清除步驟

若要刪除資料庫中BizTalkMsgBoxDb的所有數據，請使用 BHM 狀況監控 (BHM) 工具。

BizTalkDTADb 資料庫清除選項

若要從BizTalkDTADb資料庫中刪除所有數據，請使用 BHM 狀況監控 (BHM) 工具。 否則，請使用下列其中一種方法。

• 方法 1：

  1. 備份所有 BizTalk Server 資料庫。

  2. 執行預 dtasp_PurgeAllCompletedTrackingData 存程式。 如需預存程式的 dtasp_PurgeAllCompletedTrackingData 詳細資訊，請參閱 如何從 BizTalk 追蹤資料庫手動清除數據。

     注意事項

     此動作會刪除所有已完成的訊息。

• 方法 2：

  1. 備份所有 BizTalk 資料庫。

  2. 執行預 dtasp_CleanHMData 存程式。 只有在資料庫包含許多必須移除的不完整實例時 BizTalkDTADb ，才使用此選項。

     如果要執行這項操作，請依照下列步驟執行：

     1. 停止所有 BizTalk 主機、服務和自定義隔離適配卡。 如果您使用 HTTP 或 SOAP 配接器，請重新啟動 IIS 服務。
     2. 在 dtasp_CleanHMData 資料庫上 BizTalkDTADb 執行預存程式。
     3. 重新啟動所有主機和 BizTalk Server服務。

BizTalk Server 2004 年僅限步驟

如果您需要協助來分析 BHM 資料或 PSSDiag 輸出，請連絡 Microsoft 客戶支援服務。 如需客戶支援服務電話號碼的完整清單，以及支援成本的相關信息，請參閱連絡 Microsoft 支援服務。

適用於

• BizTalk Server 2009
• BizTalk Server 2010
• BizTalk Server 2013
• BizTalk Server 2013 R2
• BizTalk Server 2016
• BizTalk Server 2020