檢查清單：維護和疑難解答 BizTalk Server 資料庫

BizTalk Server 資料庫及其健康情況對於成功的 BizTalk Server 資料庫傳訊環境非常重要。 本主題列出在維護或疑難解答 BizTalk Server 資料庫時必須遵循的步驟。

• 維護 BizTalk Server 資料庫

• 針對 BizTalk Server 資料庫進行疑難解答

維護 BizTalk Server 資料庫

• 停用 [自動更新統計數據 ] 和 [ 自動建立統計數據] 選項（僅適用於 BizTalk Server MessageBox 資料庫）。 根據預設，這些設定會設定為 BizTalk Server 組態的一部分。 您不應該對這些設定進行變更。

  若要查看這些設定是否已停用，請在 SQL Server 中執行下列預存程式：

  SELECT DATABASEPROPERTYEX('BizTalkMsgBoxDB', 'IsAutoCreateStatistics') AS IsAutoCreateStatistics
  SELECT DATABASEPROPERTYEX('BizTalkMsgBoxDB', 'IsAutoUpdateStatistics') AS IsAutoUpdateStatistics
  

  傳回的值應該是 0 ，表示設定已停用。 如果未傳回 0 ，請在 SQL Server 中執行下列命令來停用設定：

  ALTER DATABASE BizTalkMsgBoxDB SET AUTO_CREATE_STATISTICS OFF
  ALTER DATABASE BizTalkMsgBoxDB SET AUTO_UPDATE_STATISTICS OFF
  

  如需這些設定的詳細資訊，請移至 當您嘗試連線到 BizTalk Server 中的 BizTalkMsgBoxDb 資料庫時，遇到封鎖、死結狀況或其他 SQL Server 問題。

• 設定最大平行度屬性。 根據預設，此設定會設定為 BizTalk Server 組態的一部分。 您不應該對這些設定進行變更。

  在裝載 BizTalk Server MessageBox 資料庫的 SQL Server 實例上，將平行處理原則的最大程度 run_value 和 config_value 屬性值設定為一個 （1）。 若要檢查 [平行處理原則的最大程度] 設定，請針對 SQL Server 中的 Master 資料庫執行下列預存程式：

  exec sp_configure 'max degree of parallelism'
  

  如果 run_value 和 config_value 未設定為一個值（1），請在 SQL Server 中執行下列預存程式：

  exec sp_configure 'max degree of parallelism', '1' reconfigure with override
  

  如需有關 Max Degree of Parallelism 設定如何影響 BizTalk Server 的詳細資訊，請移至 當您嘗試連線到 BizTalk Server 中的 BizTalkMsgBoxDb 資料庫時，可能會遇到封鎖、死結狀況或其他 SQL Server 問題。

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

  BizTalk Server 資料庫中大部分的索引都是叢集式索引（索引標識符：1）。 DBCC SHOWCONTIG 命令可用來顯示 BizTalk Server 資料庫中數據表的片段資訊。 這些索引是以 GUID 為基礎，因此發生碎片化是正常的。 如果 DBCC SHOWCONTIG 的掃描密度值小於 30%，則可以在停機期間重建索引。 BizTalk Server 資料庫中的許多數據表都包含使用 DataType 定義的數據行，其中無法完成在線索引編制。 因此，BizTalk Server 資料庫中數據表的索引不應該在 BizTalk 處理數據時重建。

  如需如何重建 BizTalk 索引的詳細資訊，請移至 當您嘗試連線到 BizTalk Server 中的 BizTalkMsgBoxDb 資料庫時，遇到封鎖、死結狀況或其他 SQL Server 問題。

  您也可以使用 sys.dm_db_index_physical_stats 函式來尋找 SQL Server 中的片段資訊。 如需詳細資訊，請參閱 sys.dm_db_index_physical_stats （Transact-SQL） 。

• 監視資料庫是否有鎖定、區塊或死結。

  這是 BizTalk Server 所使用的 SQL Server 資料庫上發生鎖定和阻塞的預期行為。 不過，預計這些鎖定或區塊不會持續太長時間。 BizTalk Server 所使用 SQL Server 資料庫的擴充封鎖和死結是潛在問題的指標。

  針對 BizTalk Server 所使用的 SQL Server 資料庫發生死結和封鎖的目前已知原因，請移至 當您嘗試連線到 BizTalk Server 中的 BizTalkMsgBoxDb 資料庫時，遇到封鎖、死結狀況或其他 SQL Server 問題。

• 監視資料庫和數據表的大小。

  BizTalk Server MessageBox 資料庫的大小通常不超過 5 GB。 BizTalkMsgBoxDb 資料庫不應該持有任何數據，而且應該視為緩衝區，直到處理數據或移至 BizTalkDTADb 資料庫為止。 具有強大 SQL Server 後端和許多長時間執行協調流程的環境，可能會有大於 5GB 的 BizTalkMsgBoxDb 資料庫。 在沒有長時間運行的編排流程的高容量環境中，BizTalk Server MessageBox 資料庫應小於 5GB。

  BizTalk Server 追蹤資料庫的大小可能會有很大的差異，但如果查詢效能大幅降低，追蹤資料庫可能太大。 一般來說，若 BizTalk Server 追蹤資料庫超過 15 至 20 GB，就會被視為過大，並可能對效能產生不利影響。

  下列問題可能歸因於 BizTalk Server 資料庫太大：

  • BizTalk Server MessageBox 資料庫會繼續成長，而數據大小（不只是記錄檔）仍然很大。 BizTalk Server處理甚至簡單的訊息流程時，所需時間比平常更長。
  • 群組中樞查詢花費的時間比正常時間長，甚至可能會逾時。
  • 資料庫記錄檔永遠不會被截斷。
  • BizTalk SQL Agent 作業的執行速度比正常慢。
  • 相較於一般，某些數據表很大，或有太多數據列。

  BizTalk Server 資料庫可能會因為數個原因而變得很大，包括：

  • BizTalk SQL Agent 作業未執行
  • 過多的暫停訊息或服務實例
  • 磁碟失敗
  • 高階追蹤
  • BizTalk Server 節流
  • SQL Server 效能不佳
  • 網路延遲問題

  同樣地，您可以在表格中擁有太多行。 沒有過多行的固定數量。 此外，此數據列數目會因數據表中儲存的數據種類而有所不同。 例如，具有超過1百萬個數據列 的dta_DebugTrace 數據表可能有太多數據列。 具有超過 200,000 個數據列 的HostNameQ_Suspended 數據表可能會有太多數據列。

  請確保您了解您的環境中所期望的內容，以判斷是否發生了數據問題。

• 在 BizTalk Server 主機上啟用追蹤。

  根據預設，預設主機上會啟用追蹤。 BizTalk 需要在單一主機上核取 [允許主機追蹤 ] 選項。 啟用追蹤時，追蹤數據譯碼服務 （TDDS） 會將追蹤事件數據從 BizTalk Server MessageBox 資料庫移至 BizTalk Server 追蹤資料庫。 如果未將任何 BizTalk Server 主機設定為 允許主機追蹤，或追蹤主機已停止，則 TDDS 將停止運行，並且 BizTalk Server MessageBox 資料庫中的 TrackingData_x_x 數據表會不受控制地增長。

  因此，應該使用 [允許主機追蹤] 選項來設定專用的 BizTalk Server 主機。 如需設定專用追蹤主機的詳細資訊，請參閱 設定專用追蹤主機。

  若要允許 TDDS 在大量案例中維護新的追蹤事件，您可以建立單一追蹤主機的多個實例，但不應設定多個主機來進行追蹤。

• 使用正確的 BizTalk SQL Server Agent 作業。

  執行 BizTalk Server SQL Agent 作業對於管理 BizTalk Server 資料庫及維護最佳效能至關重要。

  • 備份 BizTalk Server SQL Server Agent 作業是唯一支援備份 BizTalk Server 資料庫的方法。 此作業會要求您設定所有 BizTalk Server 資料庫以使用完整恢復模式。 您應該為狀況良好的 BizTalk Server 環境設定此作業。 只有當 SQL Server 服務停止且所有 BizTalk Server 進程都停止時，您才可以使用 SQL Server 方法來備份 BizTalk Server 資料庫。

    如需設定 SQL Agent 備份 BizTalk Server 作業時使用 SQL Server 完整恢復模式的詳細資訊，請參閱完整恢復模式下的記錄傳送或備份。

  • SQL Server Agent 作業 MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb 被設計為可以無限期執行。 因此，SQL Agent 作業歷程記錄可能不會指出此 SQL Agent 作業已順利完成;此行為是設計方式。 如果發生失敗，作業會在1分鐘內重新啟動並繼續持續運行。 因此，通常可以忽略此作業的失敗通知。

    如果MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb SQL Server Agent 作業的作業歷程記錄指出此作業會持續失敗並重新啟動，則可能需要進一步調查失敗/重新啟動週期的原因。

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

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

    針對 BizTalk Server SQL Server Agent 作業進行疑難解答時，請確認除了 MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb 以外的所有 SQL Agent 作業都順利完成且未發生錯誤。

  如需關於在 SQL Server 中所使用的 BizTalk Server SQL Agent 作業的更多資訊：

  • 資料庫結構和作業
  • BizTalk Server 中 SQL Server Agent 作業的描述

• 監控和結束已暫停的運行個體。

  服務實例可以暫停（可繼續）或暫停（不可繼續）。 這些服務實例可能是傳訊、編排或端口。 BizTalk Server 使用 BizTalk Server 管理控制台中的 [群組中樞] 頁面，或使用 Terminate.vbs 腳本來容納終止和移除這些實例。 如需 Terminate.vbs 腳本的詳細資訊，請參閱 移除暫停的服務實例。

  您也可以使用 Terminator 工具來移除已暫停的實例。 終止符工具隨附於 BizTalk 健康情況監視器中。

  「孤兒」和「殭屍」一詞通常交替使用。 孤立或殭屍訊息是沒有相關聯服務實例的訊息，通常是因為服務實例在收到訊息之前已終止。 沒有任何相關聯訊息的孤兒或殭屍服務，指的是一種沒有任何關聯消息的服務。 如需 BizTalk Server 中殭屍訊息和服務實例的詳細資訊，請參閱 BizTalk Server 中的 Zombies。

• 請監控 PhysicalDisk 效能物件的效能計數器。

  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 資料庫高可用性的詳細資訊，請參閱 為 BizTalk Server 資料庫提供高可用性。

• 請遵循 BizTalk Server 資料庫的最佳做法。 請參閱 維護 BizTalk Server 資料庫的最佳做法。

針對 BizTalk Server 資料庫進行疑難解答

執行下列工作，針對 BizTalk Server 資料庫的任何問題進行疑難解答。

• 確定已啟用並執行所有必要的 BizTalk SQL Server Agent 作業。

  除了 MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb 作業之外，所有 BizTalk SQL Server Agent 作業都應該啟用並成功執行。 請勿停用任何其他作業。
  
  如果發生失敗，請使用 SQL Server 中的 [ 檢視歷程記錄 ] 選項來檢視錯誤資訊，然後據以針對失敗進行疑難解答。 請記住， MessageBox _Message_ManageRefCountLog_BizTalkMsgBoxDb SQL Server Agent 作業會無限執行。 因此，只有當作業歷程記錄報告作業持續失敗並重新啟動時，才應該擔心。

• 使用 MsgBoxViewer 工具來分析 BizTalk MessageBox 和其他資料庫。

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

  當 BizTalk Server 執行速度比平常慢時，請執行 MsgBoxViewer 工具，按一下以選取 [選擇性查詢 ] 索引標籤上的所有查詢，然後檢閱產生的 HTML 報告，以尋找任何問題。 [ 摘要報告] 區段會以黃色列出警告，並以紅色列出潛在問題。

  此外，您可以使用 MsgBoxViewer 工具來判斷哪些數據表是最大的數據表，而且記錄最多。 如需通常成長大型數據表的清單，以及有關如何管理這些數據表的指示，請參閱 大型成長的 BizTalk Server 資料庫數據表。

• 使用終止符工具來解決 MsgBoxViewer 工具所識別的問題。

  終止符工具隨附於 BizTalk 健康情況監視器中。 此工具可讓用戶輕鬆地解決 BizTalk MsgBoxViewer 工具所識別的任何問題。

• 調查死結情境。

  在死結案例中，啟用 SQL Server 上的 DBCC 追蹤，讓死結資訊寫入 SQLERROR 記錄。 在 SQL Server 中，執行下列語句來啟用死結案例的 DBCC 追蹤：

  DBCC TRACEON (1222,-1)
  

  您也可以使用 PSSDIAG 公用程式，在 Lock：Deadlock 事件和 Lock：Deadlock Chain 事件上收集數據。 如需詳細資訊，請參閱 PSSDIAG 資料收集公用程式。

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

• 尋找封鎖的處理程序。

  您可以使用 SQL Server 中的活動監視器來取得鎖定系統進程的伺服器進程識別碼（SPID）。 然後，您可以執行 SQL Profiler 來判斷在鎖定 SPID 中執行的 SQL 語句。 您可以使用 PSSDIAG 公用程式，針對 SQL Server 中的鎖定和封鎖問題進行疑難解答。 公用程式會擷取已啟用封鎖腳本的所有 Transact-SQL 事件。 如需詳細資訊，請參閱 PSSDIAG 資料收集公用程式

  在 SQL Server 中，您可以指定 封鎖的進程閾值 設定，以判斷哪些 SPID 或 SPID 封鎖的時間超過您指定的臨界值。 如需已封鎖進程閾值選項的詳細資訊，請參閱 封鎖的進程閾值選項。

  當您在 SQL Server 中遇到鎖定或封鎖問題時，您可以連絡 Microsoft客戶支援服務。

• 刪除所有垃圾數據。

  如果資料庫已成長為太大，而且資料庫中所包含的數據將不再需要，則慣用的方法是刪除數據。 謹慎： 請勿在業務關鍵或需要數據的任何環境中使用此方法。

  若要清除 BizTalkMsgBox 資料庫：

  1. 下載並安裝 BizTalk Health Monitor 中包含的 Terminator 工具。

  2. 請遵循 如何在測試環境中從 MessageBox 資料庫手動清除數據 主題中的步驟，在 BizTalk MessageBox 資料庫中建立bts_CleanupMsgbox預存程式。

  3. 使用終止符工具來執行bts_CleanupMsgbox預存程式，並清除 BizTalk MessageBox 資料庫。

     bts_CleanupMsgbox預存程式會刪除數據。 在生產環境中執行此預存程式時請小心。

  4. 重新啟動所有主機和 BizTalk Server 服務。

  若要清除 BizTalkDTADb 資料庫：

  • 方法 1

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

  • 方法 2：只有在 BizTalkDTADb 資料庫包含許多必須移除的不完整實例時，才使用此選項。

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

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

如果您想要協助分析 MsgBoxViewer 資料或 PSSDIAG 輸出，請連絡 Microsoft客戶支援服務。 在您連絡客戶支援服務之前，請先壓縮 MsgBoxViewer 數據、PSSDIAG 輸出和更新的事件記錄檔（.evt 檔案）。 您可能必須將這些檔案傳送至 BizTalk Server 支持工程師。

下一步

• 維護 BizTalk Server 資料庫的最佳做法

• 大規模成長的 BizTalk Server 資料庫數據表

• 疑難解答的工具和公用程式

另請參閱

不應該變更的 SQL Server 設定