BizTalk Server資料庫優化後設定

除了遵循預先設定資料庫優化中的建議之外，應該遵循幾個步驟，在安裝 BizTalk Server BizTalk Server並設定BizTalk Server資料庫之後，將SQL Server資料庫效能優化。 本主題提供這些優化的清單。

預先配置BizTalk Server資料庫的空間，並將BizTalk Server資料庫的自動成長設定定義為固定值，而不是百分比值

• SQL Server資料庫自動成長是阻礙BizTalk Server資料庫效能的封鎖作業。 因此，請務必事先為BizTalk Server資料庫配置足夠的空間，以將資料庫自動成長的次數降到最低。

• 資料庫自動成長應該設定為固定的 MB 數目，而不是指定檔案成長以 MB 為單位的百分比， (指定檔案成長) 。 如果自動成長髮生，則應該這麼做，其會以測量方式進行，以降低過度資料庫成長的可能性。 大型檔案的成長增量通常不超過 100 MB () 、中型檔案) 的 10 MB (，或小型檔案) 的 1 MB (。

• 當SQL Server增加檔案的大小時，必須先初始化新的空間，才能使用它。 這是封鎖作業，牽涉到以空白頁面填滿新空間。 在 Windows Server 2003 或更新版本上執行的 SQL Server 2005 支援「立即檔案初始化」。 這可大幅降低檔案成長作業的效能影響。 如需詳細資訊，請參閱SQL Server 2008 - 資料庫檔案初始化。 本主題提供啟用立即檔案初始化的步驟。

將備份BizTalk Server輸出目錄移至專用 LUN

將備份BizTalk Server (完整和記錄備份) 輸出目錄移至專用 LUN，編輯步驟 1 和 2 (插入備份BizTalk Server [BizTalkMgmtDb] 作業的新輸出路徑) 。 將備份BizTalk Server輸出目錄移至專用 LUN 時，當作業執行時，寫入至與讀取作業不同的磁片時，將會減少磁片 I/O 競爭。

確認 SQL Agent 作業BizTalk Server正在執行

BizTalk Server包含數個SQL Server Agent作業，可執行重要功能，讓您的伺服器運作正常且狀況良好。 您應該監視這些作業的健康情況，並確保它們正在執行，而不會發生錯誤。 BizTalk Server中效能問題的其中一個最常見原因是 SQL Agent 作業未執行BizTalk Server，這可能會導致 MessageBox 和 Tracking 資料庫未核取。 請遵循下列步驟，確保 SQL Agent 作業BizTalk Server執行，而不會發生問題：

BizTalk Server中效能問題的其中一個最常見原因是 SQL Agent 作業未執行BizTalk Server，這可能會導致 MessageBox 和 Tracking 資料庫未核取。 請遵循下列步驟，確保 SQL Agent 作業BizTalk Server執行，而不會發生問題：

• 確認SQL Server Agent服務正在執行。

• 確認BizTalk Server安裝的SQL Server Agent作業已啟用並成功執行。

  BizTalk Server SQL Server Agent作業很重要，如果作業未執行，系統效能會隨著時間降低。

• 確認BizTalk Server SQL Server Agent作業會及時完成。

  設定 Microsoft Operations Manager (MOM) 2005 或 Microsoft System Center Operations Manager 2007 來監視作業。

  您應該注意特定作業特有的排程：

  • MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb作業預設會持續執行。 監視軟體應該將此排程納入考慮，而不會產生警告。

  • MessageBox_Message_Cleanup_BizTalkMsgBoxDb作業未啟用或排程，但每隔 10 秒就會由MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb作業啟動。 因此，不應該啟用、排程或手動啟動此作業。

• 確認已正確設定SQL Server Agent服務的啟動類型。

  確認SQL Server Agent服務已設定為[自動] 的 [啟動類型]，除非SQL Server Agent服務設定為 Windows Server 叢集上的叢集資源。 如果SQL Server Agent服務設定為叢集資源，則您應該將啟動類型設定為手動，因為服務將由叢集服務管理。

設定追蹤資料的清除和封存

請遵循下列步驟，確保已正確設定追蹤資料的清除和封存：

• 請確定名為 DTA 清除和封存 的 SQL Agent 作業已正確設定、啟用且成功完成。 如需詳細資訊，請參閱 設定 DTA 清除和封存作業。

• 請確定作業可以儘快清除追蹤資料，就像產生連入追蹤資料一樣快。 如需詳細資訊，請參閱 測量最大永續性追蹤輸送量。

• 檢閱虛清除和硬式清除參數，以確保您將資料保持在最佳時間長度。 如需詳細資訊，請參閱 封存和清除 BizTalk 追蹤資料庫。

• 如果您只需要清除舊資料，而且不需要先封存，請變更 SQL Agent 作業以呼叫名為 dtasp_PurgeTrackingDatabase的預存程式。 如需詳細資訊，請參閱 從 BizTalk 追蹤資料庫清除資料。

監視和減少 DTC 記錄檔磁片 I/O 競爭

Microsoft 分散式交易協調器 (MS DTC) 記錄檔可能會成為大量交易環境中的磁片 I/O 瓶頸。 當使用支援交易的配接器時，例如SQL Server、MSMQ 或 MQSeries，或在多 MessageBox 環境中，尤其如此。 交易式配接器會使用 DTC 交易，而多 MessageBox 環境會廣泛使用 DTC 交易。 為了確保 DTC 記錄檔不會成為磁片 I/O 瓶頸，您應該監視 DTC 記錄檔位於SQL Server資料庫伺服器 () 磁片的磁片 I/O 使用量。 如果 DTC 記錄檔所在磁片的磁片 I/O 使用量過長，請考慮將 DTC 記錄檔移至更快的磁片。 在叢集化SQL Server的環境中，這不是大部分的考慮，因為記錄檔已經位於共用磁片磁碟機上，這可能是具有多個軸的快速 SAN 磁片磁碟機。 不過，您仍應該監視磁片 I/O 使用量，因為它可能會成為非叢集環境中的瓶頸，或 DTC 記錄檔位於與其他磁片密集檔案的共用磁片上時。

為了確保 DTC 記錄檔不會成為磁片 I/O 瓶頸，您應該監視 DTC 記錄檔位於SQL Server資料庫伺服器 () 磁片的磁片 I/O 使用量。 如果 DTC 記錄檔所在磁片的磁片 I/O 使用量過多，請考慮將 DTC 記錄檔移至更快的磁片。

在叢集化SQL Server的環境中，這不是大部分的考慮，因為記錄檔已經位於共用磁片磁碟機上，這可能是具有多個軸的快速 SAN 磁片磁碟機。 不過，您仍應該監視磁片 I/O 使用量，因為它可能會成為非叢集環境中的瓶頸，或 DTC 記錄檔位於與其他磁片密集檔案的共用磁片上時。

分隔 MessageBox 和追蹤資料庫

因為 BizTalk MessageBox 和 BizTalk 追蹤資料庫是最作用中的資料庫，所以建議您將資料檔案和交易記錄檔放在專用磁片磁碟機上，以減少磁片 I/O 競爭問題的可能性。 例如，針對 MessageBox 和 BizTalk 追蹤資料庫檔案，您需要四個磁片磁碟機，每個磁片磁碟機各一個：

• MessageBox 資料檔案 ()

• MessageBox 交易記錄檔 (s)

• BizTalk 追蹤 (DTA) 資料檔案 ()

• BizTalk 追蹤 (DTA) 交易記錄檔 (s)

  分隔 BizTalk MessageBox 和 BizTalk 追蹤資料庫，以及分隔不同實體磁片上的資料庫檔案和交易記錄檔，會被視為減少磁片 I/O 競爭的最佳做法。 請嘗試盡可能將磁片 I/O 分散到多個實體軸上。 您也可以將 BizTalk 追蹤資料庫放在專用的SQL Server，以減少磁片 I/O 競爭，不過，您仍應遵循上述做法來分隔資料檔案和交易記錄檔。

優化BizTalk Server資料庫的檔案群組

請遵循優化 Databases1 的檔案群組和「BizTalk Server資料庫優化」白皮書中的步驟，為BizTalk Server資料庫建立其他檔案群組和檔案。 這可大幅提升單一磁片設定中BizTalk Server資料庫的效能。