• 發行項

SQL Q & A 資料庫的一致性、 暫存的資料表及其他資訊

Paul S. Randal

Q其中一個 SQL Server 2005 資料庫上，我已經注意到一些很奇怪的行為。 我們以我們夜間資料庫維護的一部分的資料庫上執行一個 DBCC CHECKDB，並某些住宿，DBCC 會傳回損毀的錯誤。 怪重點是，我們沒有看到 [頁面的總和檢查碼錯誤期間前一天，如果我以手動方式執行 DBCC CHECKDB 早上維護的工作失敗後，損毀會消失。 您可以解釋發生什麼事？ 這有已發生的有關每個月，我擔心我無法信任的 DBCC CHECKDB

A請參閱您有 DBCC CHECKDB，做為您定期維護的一部分，和頁面的總和檢查碼會啟用不錯。 當發生時，您所描述的行為可以非常 disconcerting — 它幾乎看起來 DBCC CHECKDB 會提供不正確的結果。 但這種情況下不會發生在定期經常 — 不有損毀的任何執行階段指示並 DBCC CHECKDB 找到損毀，然後許多時間在損毀時消失再次執行 DBCC CHECKDB。 讓我們採取這個步驟的步驟。

先，很常見的報告的 DBCC CHECKDB 無法已在一般的資料庫作業期間報告的損毀。 雖然頁面的總和檢查碼偵測由 I / O 子系統所造成的損毀的好方法，它們是有效資料的頁面會讀取由 SQL Server，發生損毀之後時，只。

假設資料的資料頁都有套用到頁面總和檢查碼，它已損然後毀某一點稍後由 I / O 子系統。 即使在頁面總和檢查碼會偵測到損毀，它仍然是只在頁面到記憶體讀取由 SQL Server 驗證頁面總和檢查碼，會發現損毀時。 如果 SQL Server，永遠不會讀取該頁面，將永遠不會發現損毀。 這就是為何它是很重要，啟用頁面的總和檢查碼，並將定期執行一致性檢查，一致性檢查將會讀取驗證其頁面總和檢查碼和探索盡早損毀資料庫中的所有網頁。

您的情況，看起來，如果在損毀發生的已做為一般的資料庫作業的一部分中未讀取的資料頁面中，，因此，損毀未發現 DBCC CHECKDB 讀取損毀的頁面之前。 雖然看來，如果頁面總和檢查碼沒有偵測損毀，也應該，則不然。

第二個，消失 「 損毀可以很容易發生的連續執行 DBCC CHECKDB，但只在兩個 DBCC 執行之間發生變更的資料庫之間。 假設確實的損毀頁面，DBCC CHECKDB 會報告為已損毀。 現在假設頁面會再從解除配置資料表 (例如，因為它會變成空白的)。 後續的 DBCC CHECKDB 將會無法讀取這一次並因此將不會報告的損毀。 DBCC CHECKDB 會讀取只會配置網頁 (表示網頁目前正使用中)。 您的情況我在猜測其餘的夜間的維護工作包括索引重建或重新組織，兩者都可以大幅改變配置給特定物件或索引頁面組。 這會帳戶，您所看到的行為。 為副作用的索引重建解除配置的損毀的頁面，然後就回初始狀態下的 DBCC CHECKDB。

若要攔截損毀的頁面，變更您的維護工作，讓它停止如果 DBCC CHECKDB 步驟失敗。 這的種方式您可以手動確認，損毀，並採取進一步的動作。

Q我們打算直接將略過 SQL Server 2005 的 SQL Server 2008，在從 SQL Server 2000 升級。 但是，我擔心 tempdb。 這已經造成問題的在 SQL Server 2000，我們有許多的短期的暫存資料表。 從哪些我瞭解，tempdb 多大量用於現在 (中 SQL Server 2005 和 SQL Server 2008)]，，因此特別提供對進行以避免在升級後的置放的效能。 您可以解釋為什麼這是大小寫，我們應該做？

A從您的問題，我猜測您所必須實作許多短期的暫存資料表建立由多個資料庫連線時所經常需要在每個處理器一檔案 tempdb 架構。 而您可能有也必須啟用 1118 追蹤的旗標 (請參閱 tempdb 資料庫的並行處理增強功能「 如需詳細資訊這)。

雖然有可能在更重 tempdb 中使用 SQL Server 2005 指定時間之後開始您可能會無法看到這除非您特別使用依賴 tempdb 的功能。 請注意如果您採取解決方案，發生與 SQL Server 2000 的 tempdb 效能問題並升級到 SQL Server 2008 在相同的硬體上，您應該在許多情況下看到效能問題會減輕稍微由於的 SQL Server 的儲存引擎，在 SQL Server 2005 中某些 tempdb 的特定變更。

是，執行大量使用 tempdb SQL Server 2005 和 SQL Server 2008 上，功能：

  • 線上索引作業
  • DML 觸發程序
  • 多重作用結果集 (MARS)
  • 快照集隔離 (交易層級和陳述式的層級)

這些功能的所有四個會使用稱為 「 版本控制的基礎技術，來儲存各種資料記錄的時間點 (Point-in-time 版本。 簡單地說這些記錄的版本會儲存在 tempdb 的版本儲存區與共用相同的版本儲存在單一的 tempdb 的所有使用者資料庫。 在多個您可以使用這些功能，heavier 版本儲存區的使用和因此 tempdb 會，更可能有將及效能上的影響。

任何成功升級，關鍵在於實作代表的實際執行負載，在使用新的結構描述測試系統上，並將測量效能，以避免的意外，您可能會遇到如果您是要直接進入實際執行中。

不幸的是，討論是方式超出範圍這個資料行的封面深入，但有可用的我會建議您簽出一些絕佳資源：

Q我們正在實作夜間資料庫維護計劃，包括改善索引的效能。 我聽說的設定索引的 「 填滿因素 」 選項可以完全移除需要維護索引。 這是真的嗎？ 看來我們的資料庫中的某些索引會從分散，有些沒有。 應該我們設定預設的資料庫會套用到所有的索引填滿因數並如果，什麼值應該我們使用嗎？

A填滿因數設定可以確實用於部分降低需要索引維護，但很少可以它用於要完全移除需要。 總而言之，填滿因素將會指示儲存引擎建立或重建時，保留特定頁面中的叢集及非叢集索引的可用空間的百分比。 (請注意填滿因素將無法維護規則插入 / 更新 / 刪除作業期間)。 填滿因數的 90，執行個體，留下 10%的可用空間。 0 或 100 兩者的填滿因素會保留 (已經被更混淆的來源) 沒有可用空間。

其概念是空間會保留在的頁面可讓資料錄，展開 [頁面上的] 或 [頁面上，而不引起的昂貴，導致分散程度的作業，稱為頁面分割要插入新資料錄)。 讓頁面可以成為更穩定地完整，直到下一個索引的維護作業，再重設填滿因素的執行，您可以指定可用空間的百分比。 秘訣是選擇最小化頁面的分割索引的維護作業之間的百分比。

OLTP (線上交易處理) 資料庫中，還有沒有簡單的答案，除了若要選擇填滿因數，為每個索引的基礎上 trial 和錯誤。 對於資料倉儲，索引位置不變更，填滿因素都應該是 100%(表示保留頁面沒有可用空間)。 因為各種不同的索引，最佳的填滿因素是通常不同是很常見從預設值為 100%，變更資料庫的預設的填滿因數。 SQL Server 2008 線上叢書 》"中的主題 填滿因數「 有更多的資訊，此。

其中一個選項是變更索引，以便頁面分割不會發生。 這可能涉及變更索引鍵，以便插入不隨機 (執行個體，藉由不使用隨機 GUID 主索引鍵)，或不允許變更大小的可變長度資料行的作業。

Q我們要將會移動到 SQL Server 2008 只要 SP1 就出而且其中功能，我們正在轉寄使用 FILESTREAM，它會移除資料行值 2GB 大小限制。 [開始] 設計下一版的我們的結構描述，以使用 FILESTREAM 資料型別，我們有是任何的缺點或我們應該要知道的問題之前，可能導致問題的實際執行嗎？

A主意永遠在智慧型，判斷新功能的所有特性之前，先設計到新的結構描述或特別是一個一樣的 FILESTREAM 利用本身，SQL Server 之外的技術的應用。 大部分的您需要的資訊被包含在我撰寫為 SQL Server 小組的呼叫一本白皮書中 」 SQL Server 2008 中的 FILESTREAM 存放." 我高度建議您在閱讀的紙張，如在完整的討論，但我將摘要列出以下問題的主要區域。

先，FILESTREAM) 資料儲存在 NTFS 檔案系統，而不是在 SQL Server 資料檔案。 有不同的組態步驟必須採取以確保 NTFS 執行非常大量的單一目錄例如關閉 8.3 產生的名稱中的檔案與設定 NTFS 叢集大小，適當地，而且可能分隔，FILESTREAM 到的資料分開的實體磁碟其他資料。

第二個，您應該確保使用 FILESTREAM 儲存的資料的平均大小可以 1 MB 或更高。 研究已顯示的資料的大小小於 256KB 的並且有時候 256 KB 及 1 MB，之間更好的效能可以可以獲得儲存直接在 SQL Server 資料，而不使用如 FILESTREAM 機制。

第三個，您應該考慮將 FILESTREAM 資料執行作業。 部分的更新程式不支援所以即使 200MB 資料值的單一位元組的更新將結果所建立的全新 200MB 值的 FILESTREAM 的資料。 分開的昂貴的作業，這會導致可進一步降低效能的 NTFS-層級分散程度。 部分更新是否普及，在應用程式中的某些批次處理機制可能必須避免重複的更新單一 FILESTREAM 值。

最後，您應該考慮跨功能相容性的 FILESTREAM 與高可用性的技術。 FILESTREAM 完全支援備份及還原作業 (包括時間點 (Point-in-time 修復)、 記錄傳送和複寫。 不，但是，相容資料庫鏡像在 SQL Server 2008 中任何方式。 (我已經被告知這將會在下一版的 SQL Server 中修正)。

這是只的事情，要考慮愛好。 在完整的圖片的您應該閱讀此白皮書。 如同任何新的功能雖然之前設計應用程式四周，, 務必執行某些廣泛的測試，以查看其功能是否符合您的需求。 假設 FILESTREAM 也包含 NTFS 儲存區，我想也預先生產的效能並嚴重損壞修復測試，以確保該無往返您設定當您移 Live。

Paul Randal S。 是管理的 Director SQLskills.com及一個 SQL Server MVP。 他處理 SQL Server 儲存引擎小組在 Microsoft 自 1999 年 2007。 Paul 撰寫 SQL Server 2005 的 DBCC CHECKDB / 修復並且負責核心的儲存引擎在 SQL Server 2008 開發期間。 Paul 是在嚴重損壞修復、 高的可用性和維護資料庫的專家，也是一般在世界的會議主持人。 在他的部落格 SQLskills.com/blogs/Paul.