檢查清單：維護和疑難排解 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問題。
設定 Parallelism 的 Max Degree of Parallelism 屬性。 根據預設，此設定會設定為BizTalk Server組態的一部分。 您不應該變更這些設定。
將平行處理原則的 Max Degree of Parallelism run_value和config_value屬性設定為裝載BizTalk Server MessageBox 資料庫之SQL Server實例上一個 (1) 的值。 若要檢查 [平行處理原則的最大程度] 設定，請在 SQL Server 中針對 Master 資料庫執行下列預存程式：
exec sp_configure 'max degree of parallelism'如果run_value和config_value未設定為 1 (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 正在處理資料時，不應該重建BizTalk Server資料庫中資料表的索引。
如需如何重建 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完整復原模式的詳細資訊，請參閱完整復原模式下的記錄傳送或備份。
MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb SQL Server Agent作業的設計目的是要無限期執行。 因此，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使用 BizTalk Server 管理主控台中的 [群組中樞] 頁面，或使用 Terminate.vbs 腳本，來容納終止和移除這些實例。 如需有關 Terminate.vbs 腳本的詳細資訊，請參閱 移除暫停的服務實例。
您也可以使用結束字元工具來移除暫停的實例。 結束字元工具隨附于BHM 狀況監控。
「孤立」 和 「zombies」 一詞通常會交替使用。 孤立或中斷訊息是沒有相關聯服務實例的訊息，通常是因為服務實例在收到訊息之前終止。 孤立或已隔離的服務是沒有任何相關訊息的服務。 如需BizTalk Server中的 zombie 訊息和服務實例的詳細資訊，請參閱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 工具隨附于 BHM 狀況監控。 MsgBoxViewer 工具適用于疑難排解，因為它提供 HTML 報表，其中包含資料表大小和資料列計數的詳細資訊。 報表也可以協助判斷BizTalk Server是否進行節流。 此外，此工具會提供BizTalk Server資料庫和BizTalk Server組態的快照集。
當BizTalk Server執行速度比平常慢時，請執行 MsgBoxViewer 工具，按一下以選取 [選擇性查詢] 索引標籤上的所有查詢，然後檢閱產生的 HTML 報告是否有任何問題。 [ 摘要報告] 區段會以黃色列出警告，並以紅色顯示潛在問題。
此外，您可以使用 MsgBoxViewer 工具來判斷哪些資料表是最大且具有最多記錄。 如需通常會成長大型資料表的資料表清單，以及有關如何管理這些資料表的指示，請參閱大型成長BizTalk Server資料庫資料表。
使用結束字元工具來解決 MsgBoxViewer 工具所識別的問題。
結束字元工具隨附于BHM 狀況監控。 此工具可讓使用者輕鬆地解決 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 資料庫：
下載並安裝包含在BHM 狀況監控中的結束字元工具。
請遵循 如何在測試環境中從 MessageBox 資料庫手動清除資料 主題中的步驟，在 BizTalk MessageBox 資料庫中建立bts_CleanupMsgbox預存程式。
使用結束字元工具來執行bts_CleanupMsgbox預存程式，並清除 BizTalk MessageBox 資料庫。
bts_CleanupMsgbox預存程式會刪除資料。 在生產環境中執行此預存程式時，請小心。
重新開機所有主機和BizTalk Server服務。
若要清除 BizTalkDTADb 資料庫：
方法 1
- 備份所有BizTalk Server資料庫。
- 執行 預存程式dtasp_PurgeAllCompletedTrackingData 。 如需預存程式的詳細資訊，請參閱 如何從 BizTalk 追蹤資料庫手動清除資料。
方法 2：只有在 BizTalkDTADb 資料庫包含許多必須移除的不完整實例時，才使用此選項。
- 備份所有BizTalk Server資料庫。
- 停止所有 BizTalk 主機、服務和自訂隔離介面卡。 如果您使用 HTTP 或 SOAP 配接器，請重新開機 IIS 服務。
- 在 BizTalkDTADb 資料庫上執行 dtasp_CleanHMData 預存程式。
- 重新開機所有主機和BizTalk Server服務。
如果您必須擁有追蹤資料，請備份 BizTalkDTADb 資料庫、將資料庫還原到另一個SQL Server，然後清除原始的 BizTalkDTADb 資料庫。
如果您想要協助分析 MsgBoxViewer 資料或 PSSDIAG 輸出，請連絡 Microsoft 客戶支援服務。 連絡客戶支援服務之前，請先壓縮 MsgBoxViewer 資料、PSSDIAG 輸出，以及更新的事件記錄檔 (.evt 檔案) 。 您可能必須將這些檔案傳送給BizTalk Server支援工程師。