維護和疑難解答 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 資料庫問題進行疑難解答。
您必須停用自動建立統計數據和自動更新統計數據選項
您必須在資料庫上BizTalkMsgBoxDb
保留 auto create statistics
和 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'
您必須正確設定平行處理原則的最大程度屬性
在執行 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 作業會 MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb
無限執行。 因此,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 腳本的詳細資訊,請參閱移除暫停的服務實例。
快取實例不會出現在 [群組中 樞 ] 頁面中,而且您無法暫停或終止它們。 此限制是數據表成長的常見原因。 若要防止 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) 檔案放在不同的磁碟驅動器上。 當 和 BizTalkDTADb
資料庫的LDF和MDF檔案BizTalkMsgBoxDb
位於相同的磁碟驅動器上時,可能會發生磁碟爭用。
如果您無法受益於訊息本文追蹤,請勿啟用此功能。 不過,當您開發和疑難解答解決方案時,最好啟用訊息本文追蹤。 如果您這樣做,請務必在完成時停用訊息本文追蹤。 啟用訊息本文追蹤時,BizTalk Server 資料庫就會成長。 如果需要啟用訊息本文追蹤的商務需求,請確認 TrackedMessages_Copy_BizTalkMsgBoxDb
和 DTA 清除和封存 SQL Server Agent 作業已順利執行。
一般而言,較小的事務歷史記錄會造成較佳的效能。 若要讓事務歷史記錄保持較小,請設定備份 BizTalk Server SQL Server Agent 作業以更頻繁地執行。
資料庫中 sp_ForceFullBackup
的 BizTalkMgmtDb
預存程式也可用來協助執行數據和記錄檔的特定完整備份。 預存程式會以值 1 更新 adm_ForceFullBackup
資料表。 下次執行備份 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_BizTalkMsgBoxDb
SQL 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 數據表。 您可以使用此資料來判斷可能存在潛在問題的位置。
資料表 | Description |
---|---|
<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 追蹤的訊息本文直接移至資料庫中的 BizTalkDTADb 這些數據表。在 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 中,實例可能會快取實例或孤立的路由失敗報告。 當暫停的實例終止時,會清除此數據表中的專案及其和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 終止符工具來截斷這些數據表。如果數據表中的序號
BizTalkMsgBoxDb
TrackingData_x_x
與BAMPrimaryImport
或BizTalkDTADb
TDDS_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
Chain 事件的數據Lock:Deadlock
。
資料庫 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
,請使用 BHM 狀況監控 (BHM) 工具。
BizTalkDTADb 資料庫清除選項
若要從BizTalkDTADb
資料庫刪除所有資料,請使用 BHM 狀況監控 (BHM) 工具。 否則,請使用下列其中一種方法。
注意
雖然這兩種方法都刪除所有訊息,但方法 2 的速度較快。
方法 1:
備份所有 BizTalk Server 資料庫。
執行預
dtasp_PurgeAllCompletedTrackingData
存程式。 如需預存程式的詳細資訊dtasp_PurgeAllCompletedTrackingData
,請參閱 如何從 BizTalk 追蹤資料庫手動清除數據。注意
此動作會刪除所有已完成的訊息。
方法 2:
備份所有 BizTalk 資料庫。
執行預
dtasp_CleanHMData
存程式。 只有當BizTalkDTADb
資料庫包含必須移除的許多不完整實例時,才使用此選項。若要這樣做,請遵循下列步驟:
- 停止所有 BizTalk 主機、服務和自定義隔離適配卡。 如果您使用 HTTP 或 SOAP 配接器,請重新啟動 IIS 服務。
- 在
dtasp_CleanHMData
資料庫上BizTalkDTADb
執行預存程式。 - 重新啟動所有主機和 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