Microsoft SQL Server tempdb 資料庫的 I/O 子系統需求

本文介紹 SQL Server 中 tempdb 資料庫的 I/O 子系統需求。

原始產品版本：Microsoft SQL Server 2005、SQL Server 2008、SQL Server 2012 SQL Server 2014
原始 KB 編號： 917047

摘要

Microsoft SQL Server 要求用來儲存系統和使用者資料庫的 I/O 子系統完全接受透過特定 I/O 主體 (WAL) 需求 Write-Ahead 記錄。 為了接受交易的 ACID 屬性，需要這些需求：Atomic、Consistent、Isolated 和 Durable。 下列參考提供 I/O 子系統合規性需求的詳細資料：

SQL Server 2000 I/O 基本概念https://technet.microsoft.com/library/cc966500.aspx

下列清單是需求的快速摘要：

• 必須維持寫入順序。
• 必須維護相依寫入一致性。
• 寫入必須一律在穩定媒體中/在穩定媒體上受到保護。
• 必須進行損毀 I/O 防護。

持久性維護對於所有其他資料庫而言仍然很重要，但tempdb資料庫可能會放寬。 下表摘要說明 SQL Server 資料庫的幾個重要 I/O 需求。

交易式扇區重寫牽涉到子系統完全記錄的作業，可讓扇區完全移動、取代或回復至原始映射。 這些重寫通常不建議使用，因為執行這類動作需要額外的額外負荷。 其中一個 defragmentation 範例是移動檔案數據的公用程式。 在保護新的扇區和數據之前，檔案中的原始扇區無法取代為新的扇區位置。 重新對應扇區必須以交易方式進行，如此一來，任何失敗，包括電源故障，都會造成原始數據的重新建立。 請確定您在這類程式期間有可用的鎖定機制，以防止無效的數據存取，進而支援 SQL Server I/O 的其他租使用者。

跨中斷的存活

tempdb 資料庫是 SQL Server 的臨時區域，並且會在每次啟動 SQL Server 重建。 初始化會取代數據在重新啟動後存取的任何需求。

交易式扇區重寫作業

為了保證復原程式的成功，例如復原和損毀復原，記錄檔記錄必須正確地儲存在穩定媒體上，才能儲存數據頁，而且不接受交易屬性就無法重寫。 這需要子系統和 SQL Server 維護特定屬性，例如寫入順序、扇區對齊和大小寫入，以及先前所述檔中所述的其他 I/O 安全屬性。 對於 tempdb 資料庫而言，損毀復原是不必要的，因為資料庫一律會在 SQL Server 啟動期間初始化。 不過，tempdb 資料庫仍然需要復原功能。 因此，WAL 通訊協定的某些屬性可以放寬。

tempdb 資料庫的儲存位置必須嚴格地根據已建立的磁碟驅動器通訊協議來執行。 在所有方面，儲存tempdb資料庫的裝置都必須顯示為實體磁碟，並提供寫入後讀取功能。 交易扇區重寫作業可能是特定實作的其他需求。 例如，SQL Server 不支援使用NTFS檔系統壓縮進行資料庫修改，因為NTFS壓縮可以重寫已經寫入並視為強化的記錄檔扇區。 在這種類型的重寫期間發生失敗，可能會導致資料庫無法使用，並損毀 SQL Server 視為安全的數據。

交易式扇區重寫作業與包含tempdb資料庫的所有 SQL Server資料庫有關。 不斷成長的擴充記憶體技術會使用裝置和公用程式，這些裝置和公用程式可以重寫 SQL Server 認為安全的數據。 例如，某些新興技術會執行記憶體內部快取或數據壓縮。 為了避免嚴重的資料庫損毀，任何扇區重寫都必須有完整的交易支援，如此一來，如果發生失敗，數據就會回復到先前的扇區映像。 這可保證 SQL Server 永遠不會暴露於非預期的中斷或數據損毀狀況。

您可以將 tempdb 資料庫放在特殊子系統上，例如 RAM 磁碟、固態或其他無法用於其他資料庫的高速實作。 不過，當您評估這些選項時，必須考慮 [ 更多資訊 ] 區段中顯示的關鍵因素。

其他相關資訊

當您評估tempdb資料庫的儲存位置時，應該仔細研究幾個因素。 例如，tempdb 資料庫使用量牽涉到但不限於記憶體使用量、查詢計劃和 I/O 決策。 tempdb 資料庫的適當調整和實作可以改善系統的延展性和回應性。 本節討論決定 tempdb 資料庫記憶體需求的關鍵因素。

高速子系統

市場上提供各種高速子系統實作，可提供 SQL Server I/O 子系統通訊協定需求，但不提供媒體的持久性。

RAM 磁碟是這類實作的常見範例之一。 RAM 磁碟會安裝必要的驅動程式，並讓部分主要 RAM 磁碟顯示為 ，並如同連接至系統的任何磁碟驅動器一樣運作。 所有 I/O 子系統都應該完全符合 SQL Server I/O 需求。 不過，RAM 磁碟顯然不是永久性媒體。 因此，RAM 磁碟之類的實作只能做為tempdb資料庫的位置，而且不能用於任何其他資料庫。

實作和部署之前要考慮的索引鍵

在這種子系統上部署tempdb資料庫之前，需要考慮幾點。 本節使用 RAM 磁碟作為討論的基礎，但在其他高速實作中也會發生類似的結果。

I/O 安全性

寫入后讀取和交易式扇區寫入的相容性是必須的。 請勿在未完全支援 SQL Server I/O 需求的任何系統上部署 SQL Server，否則您可能會損毀和遺失數據。

雙 RAM 快取 (已快取的頁面)

臨時表就像資料庫中的所有其他數據表一樣。 它們會由緩衝池快取，並由延遲寫入作業處理。 將臨時表頁面儲存在 RAM 磁碟上會導致兩次 RAM 快取，一個在緩衝池中，一個在 RAM 磁碟上。 這會直接從緩衝池的可能大小總計中擷取，而且通常會降低 SQL Server的效能。

放棄 RAM

如名稱所示，RAM 磁碟會指定主要 RAM 的一部分。 RAM 磁碟和 RAM 型檔案快取有數個實作可供使用。 有些也會啟用實體 I/O 支援作業。 RAM 型檔案快取的關鍵元素是直接從 SQL Server 使用的物理記憶體中取出。 一律具有強大的證據，證明新增 RAM 型檔案快取可改善應用程式效能，而且不會降低其他查詢或應用程式效能。

先微調

應用程式應該微調，以移除可能導致使用tempdb資料庫的不必要和不必要的排序和哈希。 許多時候，新增索引可以完全移除計劃中排序或哈希的需求，進而達到最佳效能，而不需要使用tempdb資料庫。

可能的權益點

將 tempdb 資料庫放在高速系統上的優點，只能透過應用程式工作負載的嚴格測試和測量來決定。 工作負載必須仔細研究 tempdb 資料庫可能受益於的特性，而且必須在部署之前確認 I/O 安全性。

排序和哈希作業會與 SQL Server 記憶體管理員一起運作，以判斷每個排序或哈希作業的記憶體內部臨時區域大小。 一旦排序或哈希數據超過配置的記憶體內部臨時區域，數據就可以寫入tempdb資料庫。 此演算法已在 2005 SQL Server 擴充，可減少舊版 SQL Server 的 tempdb 資料庫使用需求。

SQL Server 使用 tempdb 資料庫來處理各種涉及排序、哈希、數據列版本存放區和暫存數據表的活動：

• 臨時表是由數據頁的一般緩衝池例程所維護，而且通常不會顯示特殊子系統實作的效能優勢。
• tempdb 資料庫會當做哈希和排序的臨時區域使用。 減少這類作業的 I/O 延遲可能會有説明。 不過，請知道新增索引以避免哈希或排序可能會提供類似的好處。

使用和不使用儲存在高速子系統上的tempdb資料庫來執行基準，以比較優點。 測試的一部分應該包含不涉及排序、哈希或臨時表的使用者資料庫查詢，然後確認這些查詢不會受到負面影響。 當您評估系統時，下列效能指標會很有説明。

交易式扇區重寫範例

下列範例詳細說明 SQL Server 資料庫所需的數據安全性。

假設 RAM 磁碟廠商使用記憶體內部壓縮實作。 實作必須正確封裝，方法是提供檔案數據流的實體外觀，如同扇區已對齊和重設大小，讓 SQL Server 不會察覺並正確地受到基礎實作保護。 進一步查看壓縮範例。

• 扇區 1 會寫入裝置，並壓縮以節省空間。
• 扇區 2 會寫入裝置，並使用扇區 1 壓縮以節省空間。

當裝置與扇區 2 的數據結合時，裝置可能會執行下列動作來協助保護扇區 1 的數據。

• 封鎖所有對扇區 1 和 2 的寫入。
• 將扇區 1 解壓縮成臨時區域，將目前的扇區 1 記憶體保留為要擷取的作用中數據。
• 將扇區 1 和 2 壓縮成新的儲存格式。
• 封鎖區段 1 和 2 的所有讀取和寫入。
• 使用新的記憶體交換區段 1 和 2 的舊記憶體。 如果交換嘗試失敗 (回復) ：
  • 還原區段 1 和 2 的原始記憶體。
  • 從臨時區域移除扇區 1 和 2 合併的數據。
  • 無法執行扇區 2 寫入作業。
• 解除封鎖區段 1 和 2 的讀取和寫入。

能夠提供有關扇區修改的鎖定機制，並在扇區交換嘗試失敗時復原變更，被視為暫時符合規範。 對於使用實體記憶體進行擴充支援的實作，它會包含適當的事務歷史記錄層面，以協助保護和復原已套用至磁碟結構的變更，以維護 SQL Server 資料庫檔案的完整性。

任何啟用重寫扇區之裝置都必須以交易方式支援重寫，這樣 SQL Server 就不會暴露在數據遺失的情況下。

移動tempdb資料庫時請小心

移動tempdb資料庫時請小心，因為如果無法建立tempdb資料庫，SQL Server將無法啟動。 如果無法建立tempdb資料庫，請使用 (-f) 啟動參數來啟動 SQL Server，並將tempdb資料庫移至有效的位置。

若要變更tempdb資料庫的實體位置，請遵循下列步驟：

1. 使用語 ALTER DATABASE 句和 子 MODIFY FILE 句來變更tempdb資料庫中每個檔案的實體檔名，以參考新的實體位置，例如新磁碟。

   ALTER DATABASE tempdb MODIFY FILE 
   (name = tempdev, filename = 'C:\MyPath\tempdb.mdf')
   
   ALTER DATABASE tempdb MODIFY FILE 
   (name = templog, filename = 'C:\MyPath\templog.ldf')
   

2. 停止，然後重新啟動 SQL Server。

合作夥伴產品認證不是相容性或安全性的保證

第三方產品或特定廠商可以收到 Microsoft 標誌認證。 不過，合作夥伴認證或特定 Microsoft 標誌不會認證相容性或適合 SQL Server 中的特定用途。

支援

如果您使用子系統搭配 SQL Server 支援交易式資料庫使用的 I/O 保證，如本文所述，Microsoft 將會提供 SQL Server 和 SQL Server 型應用程式的支援。 不過，子系統的問題或造成的問題將會參考製造商。

針對 tempdb 資料庫相關問題，Microsoft 支援服務 服務會要求您重新放置 tempdb 資料庫。 請連絡您的裝置廠商，確認您已正確部署並設定裝置以供交易資料庫使用。

Microsoft 不會認證或驗證第三方產品是否正確地與 SQL Server 搭配運作。 此外，Microsoft 不會提供任何第三方產品適合與 SQL Server 搭配使用的擔保、擔保或聲明。

參考資料

如需詳細資訊，請參閱下列「Microsoft 知識庫」文章：

• 已新增其他 SQL Server 診斷以偵測未回報的 I/O 問題

• 錯誤訊息 823 可能表示 SQL Server 中的硬體問題或系統問題

• 搭配使用磁碟驅動器快取與 SQL Server

• 在 SQL Server 中支援網路資料庫檔案的描述

• Microsoft 不會證明第三方產品會與 Microsoft SQL Server

• Azure 虛擬機器 上 SQL Server 的效能指導方針

• 使用 SQL Server 2014 基數估算器優化查詢計劃

• 查詢效能