SQL q & a：動態資料和嚴重損壞修復
本月的方案以進行 SQL 成功執行的範圍展開 tempdb 及叢集用來產生半生不熟的災害重建計劃。
Paul 也經常 s。 Randal
填滿空間
Q。 我是負責實際執行伺服器之一有問題。 將 tempdb 成長大型每隔數天。 這是相當新問題。 我看不到伺服器或記憶體使用量差異的連線數目。 如何監視這種情況想知道什麼使用所有的 tempdb 空間？
答： 很多可能會變 tempdb 使用狀況的原因有：
- (用於快照集隔離或線上索引作業，例如) 的版本控制系統的使用會導致版本儲存區成長 tempdb 中。
- 因為過時之統計資料，而依序造成查詢計劃運算子該結果中的記憶體的大 spill 到 tempdb，所以無法變更的查詢計劃。
- 有人可能會部署新的應用程式程式碼會使用暫存資料表來儲存部分處理資料。
事項，有一些簡單的方法，讓您追蹤什麼。 您應該執行的第一件事是檢查整體的 tempdb 空間使用方式與動態管理檢視 (DMV) sys.dm_db_file_space_usage。 如果您擷取這個 DMV 的結果時每隔 30 秒，比方說，您可以告訴額外空間的使用是否從版本儲存區、 使用者物件或建立以協助查詢處理的物件。
如果是會佔據的所有空間的版本儲存區，您可以深入進一步使用 DMV sys.dm_tran_top_version_generators。 您要加入具有 sys.partitions 和 sys.indexes 以取得真正有用的資訊之外，但它將可讓您知道哪些資料表具有所產生的大部分版本。
如果是其他佔用空間的任何項目，您可以向下切入攻佔類似頻率 sys.dm_db_task_space_usage 的結果。 然後加入與 sys.dm_exec_requests DMV，若要找出哪一個連接和查詢佔用的空間。
如果結果並沒有被長預存程序，您可能需要檢測要定期輸出的 tempdb 空間讓您能找出哪一個陳述式在程序中的會出禍首表示它使用的程序。 我有在用戶端系統上執行此數次。
您可以找到更多有關使用這些 Dmv 白皮書，」使用 tempdb 中 SQL Server 2005."(這本白皮書也適用於較新版的 SQL Server)。
良好的叢集
Q。 我要設計用來儲存資料的新應用程式資料庫的結構描述需要。 我已閱讀了所有類型的建議選擇 「 良好 」 的叢集的索引鍵的資料表。 您可以解釋什麼讓 「 良好 」 的叢集的索引鍵，它為什麼這麼多問題？
答： 這是一個複雜的問題，而且幾乎不可能詳盡回答以下。 簡單的說，「 良好 」 的叢集的索引鍵是已仔細選擇來最小化效能不佳以及浪費的空間。 良好的叢集的索引鍵的四個品質是：窄，靜態，唯一且不斷增加：
- 縮小 (佔用較少的位元組盡可能)： 所有非叢集索引記錄包含叢集的索引鍵。 它是越大，非叢集索引中的多個空間重複資訊會使用。
- 靜態 (固定)： 變更機碼值很耗費資源。 SQL Server 不會刪除索引鍵更新 + 插入作業 (請參閱我的部落格張貼這裡)，並的隨時更新叢集的索引鍵時，非叢集索引中所有符合的資料列也需要更新。 索引鍵的變更也會造成空白空間資料檔案頁面上如果索引會在該索引鍵位置就會再次使用。
- 唯一： 這樣可避免將隱藏的四位元組行加入 uniquify 重複索引鍵值的 SQL Server，進而讓更多的索引鍵。
- 不斷增加：隨機插入並產生新的資料錄的插入模式可能會造成昂貴頁面分割作業的叢集索引。 這會導致邏輯片段和浪費的空間資料檔案頁面上。
由於這些品質良好的叢集的索引鍵，通常不符合的自然索引鍵 (比方說，其中一個衍生自資料表資料)，所以您不必使用代理鍵 (比方說，人工資料表資料行)。 BIGINT 識別資料行是很好的 surrogate 索引鍵的其中一個範例。 閱讀更多的深入解釋、 和戴婉 Tripp 的部落格類別中只要叢集索引鍵。
在發生最壞的準備
Q。 在最近的地震紐西蘭和日本的喚醒，我檢查我們損毀修復計劃，並找到它真的已經過期。 我一直不成功： 想要取得本公司必須徹底改頭換面，並測試計劃。 它們只是不認為我們不需要在嚴重損壞。 您給我一些提示如何處理這種情形與管理吗？
答： 真高興聽到您正在主動分析這些最近發生的喚醒您嚴重損壞修復 (DR) 策略。 許多公司皆可自我滿足並且在您的問題描述態度。 雖然大規模的天然災害是很少見，當地語系化的問題更像是建置引發或電力不穩是相當常見而一家公司不應該假設它是隨機棄置免疫。
即使您無法取得管理您這一方，請在沒有大規模的測試您可以執行您自己，就像從備份還原資料庫的複本。 這是測試您的備份的完整性和備份策略，以及您確定還原時間符合任何特定資料庫的最大可允許的停機時間需求。 通常，這是 DR 策略測試期間發現的第一個問題。 資料磁碟區經過一段時間會變，且 commensurately 還原時間會增加。
DR 策略的其他部分是難以測試自己，例如容錯移轉到資料庫鏡像合作關係] 或 [容錯移轉叢集。 這兩種都需要某些應用程式中斷 (兩者都使用容錯移轉和錯誤後回復)。
儘說服管理有關，而是，它們就會找到的出 DR 策略不會工作期間計劃完成後測試與所有人員現有協助您復原，還是以後災難發生時，實際到了午夜兩點請他們 上國定假日，當只答對最小的工作人員是在-手的形狀。
市面上有許多高度公開事件的公司遭受中斷，因為 DR 策略太小。 管理是否想要新聞中的下一個公司？ 聽起來或許 melodramatic，但它是公平的點。
嚴重損壞修復是在談到公司和它的用戶端的成本降至最低。 如果用戶端會因為中斷的主因，或失去信心，公司的快速復原的能力，這些可能會需要使用企業其他地方。 這很明顯地總是很傷人公司的下一行。
為 technologists，我們需要要求管理]，以將對公司的財務影響的角度來看 IT 嚴重損壞。 我發現這是在引誘管理投入時間和金錢長短和測試的 DR 策略中有效策略。 進一步了解這在我最近的部落格文章中讀取這裡。
壓縮成本
Q。 我真的想要使用資料壓縮功能在 SQL Server 2008 中減少我們儲存成本，但我已閱讀它是只針對資料倉儲，我將會造成極大的效能問題如果我嘗試在線上交易處理 (OLTP) 系統中使用它。 這是真的嗎？
答： 您已正確資料壓縮功能的原始目的是作為資料倉儲用途。 資料壓縮可減少資料表與索引記錄的大小。 這表示更多的記錄超過 8 KB 資料檔案] 頁中，而因此較少的資料檔案網頁，才能將資料儲存在磁碟上。 這將轉譯成較小的磁碟空間需求，保持壓縮的資料，會依序可以導致省下顯著的成本，因為較少企業層級儲存區是必要的資料庫。
必須有所取捨，不用多說，是資料必須在使用前先在背景解壓縮。 當讀取到 SQL Server 緩衝集區 (於記憶體中快取的資料檔案頁面中) 時，不被解壓縮資料。 它只被解壓縮時滿足查詢實際所需。 解壓縮使用 CPU 資源，因此一個交換代價就是針對 CPU 資源的空間使用方式。
典型的資料倉儲有大量的資料 (認為數百 gb 到多重 tb)。 該資料的存取模式是通常是大型的資料量讀入緩衝區集區中，一次處理，然後不使用一次的長時間足夠它已過時的記憶體用完。
以這種存取模式，其意義降至最低的讀取 I/O 操作數壓縮要尺寸小很多的資料。 這會需要較少 SQL Server 資料檔案頁，將資料儲存和讀取那些網頁的較少 I/O 作業。 這通常會導致這些類型的查詢更快速地完成。 因此另一個交換代價就是相對於 (為解壓縮資料) 的 CPU 資源的查詢速度。
如果您考慮 OLTP 工作負載，通常沒有比多高資料可在資料倉儲中。 這表示如果您使用資料壓縮，您會引起 CPU 成本最高，因為讀取資料的常數解壓縮及資料被插入或更新壓縮。 您必須考慮的 OLTP 資料庫的資料壓縮時更仔細看一下取捨。
上一步取得問題的答案，雖然資料壓縮原先所對準資料倉儲，許多 SQL Server 客戶已經找到它們有大量的 CPU 」 標頭房"在他們的伺服器上。 他們所能負擔的額外的 CPU 使用率和可能較長的查詢執行時間，可以節省大量空間，儲存與使用資料壓縮相關的成本節省效果。 資料壓縮可以 對 OLTP 環境非常有用。 只要確定您評估節省空間和效能成本您工作負載後，再進行到實際執行環境。
為節省空間，您可以使用 sp_estimate_data_compression_savings 程序讓您了解您可以預期百分比省下的。 請務必執行這項操作，因為啟用或停用資料壓縮是使用重建作業。 這可能相當昂貴本身。 如需詳細資訊，請參閱白皮書，」資料壓縮：策略、 容量計劃和最佳作法。"
.jpg)
**Paul 也經常 s。 Randal**是管理 director 的 SQLskills.com，Microsoft 地區主管與 SQL 伺服器 MVP。 他投入 SQL Server 儲存引擎小組在 Microsoft 從 1999年 2007年。 他的 SQL Server 2005 撰寫 DBCC CHECKDB/修復，並在 SQL Server 2008 開發期間是負責核心儲存引擎。 Randal 是嚴重損壞修復、 高可用性和資料庫維護的專家，身為在世界各地研討會發表演說。 在他部落格SQLskills.com/blogs/paul，以及您可以找到他在 Twitter twitter.com/PaulRandal。