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

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

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

摘要

Microsoft BizTalk Server 資料庫的健康情況對於成功的 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 statistics資料庫中保持auto update statistics和BizTalkMsgBoxDb選項停用。若要判斷這些設定是否停用，請在 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'

您必須正確設定平行處理原則的最大程度屬性

在執行 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）。您可以使用 DBCC SHOWCONTIG SQL Server 語句來顯示 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 伺服器可以正常運作。當您有大型 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 數據列的數據表可能會有太多數據列。具有超過 200,000 個 <HostName>Q_Suspended 數據列的數據表可能會有太多數據列。

使用合適的 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 資料庫。

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 資料庫。此作業會讀取數據表中的每個數據列，並比較時間戳，以判斷是否應該移除記錄。

除了MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb SQL Server Agent 作業外，所有 BizTalk SQL Server Agent 作業都應該順利執行。

服務實例可能會暫停

服務實例可以暫停（可繼續）或暫停（不可繼續）。這些服務實例可能是傳訊、編排或端口。

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

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

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

注意

殭屍訊息是已經路由處理但尚未被消耗的訊息。

如需殭屍訊息的描述，請流覽下列 MSDN 網站： BizTalk Core Engine 的 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 毫秒或更大，被視為效能不佳。

BizTalk Server 中的最佳做法

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

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

如果您無法受益於訊息本文追蹤，請勿啟用此功能。當您開發和疑難排解方案時，啟用訊息內容追蹤是個不錯的主意。如果您這樣做，請務必在完成時停用訊息內容追蹤。啟用訊息本文追蹤時，BizTalk Server 資料庫就會成長。如果需要啟用訊息本文追蹤的商務需求，請確認 TrackedMessages_Copy_BizTalkMsgBoxDb 和 DTA 清除和封存 SQL Server Agent 作業已順利執行。

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

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

BizTalk 健康監控工具用於評估現有的 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_BizTalkMsgBoxDb SQL Server Agent 作業會無限執行。因此，只有當作業歷程記錄報告作業持續失敗並重新啟動時，才應該擔心。

步驟 2：使用 BizTalk 健康監視器 (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）追蹤的事件儲存在 `BizTalkMsgBoxDb` 資料庫中，以便 TDDS 將事件移至 `BAMPrimaryImport` 資料庫。
`TrackingData_1_x`	這四個數據表會將追蹤的事件儲存在 `BizTalkMsgBoxDb` TDDS 的資料庫中，以將事件 `BizTalkDTADB` 移至資料庫。
`Tracking_Fragmentsx` `Tracking_Partsx` `Tracking_Spoolx`	其中兩個數據表位於 `BizTalkMsgBoxDb` 和 `BizTalkDTADb` 資料庫中。一個是在線，另一個是離線。在 BizTalk Server 2004 SP2 和更新版本中，SQL Server Agent 作業會將追蹤的訊息本文直接移至 `TrackedMessages_Copy_BizTalkMsgBoxDb` 資料庫中的資料表。在 BizTalk Server 2004 Service Pack 1（SP1）和早期版本的 BizTalk Server 2004 中，`TrackedMessages_Copy_BizTalkMsgBoxDb` SQL Server Agent 作業會將追蹤的訊息本文複製到 `BizTalkMsgBoxDb` 資料庫中的這些資料表。 `TrackingSpool_Cleanup_BizTalkMsgBoxDb` SQL Server Agent 作業會清理離線數據表，讓數據表上線，同時作業也會讓線上數據表脫機。
`dta_ServiceInstances`	此數據表會儲存服務實例在`BizTalkDTADb`資料庫中的追蹤事件。如果這個數據表很大， `BizTalkDTADb` 資料庫可能很大。
`dta_DebugTrace`	此數據表會將協調流程調試程式事件儲存在 BizTalkDTADb 資料庫中。
`dta_MessageInOutEvents`	此數據表會將追蹤的事件訊息儲存在 `BizTalkDTADb` 資料庫中。這些追蹤的事件訊息包括訊息內容資訊。
`dta_ServiceInstanceExceptions`	此數據表會儲存資料庫中任何暫止服務實例 `BizTalkDTADb` 的錯誤資訊。

請考慮下列情況。

<HostName>Q_Suspended 表

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

在此情境中，請恢復或終止暫停的實例。也可以使用 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 終止符工具來截斷這些數據表。

如果BizTalkMsgBoxDbTrackingData_x_x表與BAMPrimaryImport或BizTalkDTADbTDDS_StreamStatus表之間的序號有較大差距，TDDS 可能不會將數據從BizTalkMsgBoxDb數據庫中移動。若要更正此問題，請使用 BHM 工具來清除這些數據表並重設序號。
dta_DebugTrace 和 dta_MessageInOutEvents 數據表

啟用編排上圖形的dta_DebugTrace時，表格會被填入。如果 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 事件和 Lock:Deadlock Chain 事件的數據。

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

清除佇列命令和某些 SQL Server Agent 作業應該會死結。 ** 一般而言，這些作業通常會被選為死結的受害者。這些作業會出現在死結追蹤記錄中。不過，事件記錄檔中不會列出任何錯誤。因此，出現這些作業的死結是預期中的情況，您可以安心地忽略它們。

如果在死結追蹤中頻繁出現死結，而且事件記錄檔中列出相關錯誤，您可能需要處理這些死結。

步驟 4：尋找封鎖的進程

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

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

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

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

注意

當您在 SQL Server 中遇到鎖定或封鎖問題時，建議您連絡 Microsoft客戶支持服務。 Microsoft客戶支援服務可協助您設定正確的 PSSDiag 公用程式選項。

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

BizTalk Server 更新版本已移至累積更新（CU）模型。累積更新將包含最新的修正。

刪除所有數據

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

警告

請勿在業務關鍵或需要數據的任何環境中使用此方法。

BizTalkMsgBoxDb 資料庫清除步驟

若要刪除 BizTalkMsgBoxDb 資料庫中的所有資料，請使用 BizTalk 狀況監控工具。

BizTalkDTADb 資料庫清除選項

若要刪除BizTalkDTADb資料庫中的所有資料，請使用 BizTalk 健全性監控工具（BHM）。否則，請使用下列其中一種方法。

注意

雖然這兩種方法都刪除所有訊息，但方法 2 的速度較快。

方法 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 專用步驟

注意

如果您必須擁有追蹤數據，請備份 BizTalkDTADb 資料庫、將資料庫還原至另一個 SQL Server，然後清除原始 BizTalkDTADb 資料庫。

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

注意

在您連絡客戶支援服務之前，請先壓縮 BHM 報表數據、PSSDiag 輸出和更新的事件記錄檔（.evt 檔案）。您可能必須將這些檔案傳送至 BizTalk Server 支持工程師。

適用於

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

Last updated on 2023-05-11

共用方式為