SQL q & a: 重組和損毀
錯誤記錄檔和暫存資料庫檔案可能會一下子增加太快。 採取這些設定策略將有所幫助。
Paul s。 Randal
預設值為 [磁碟重組的
**問：**我已經處理一些我們已經在我們的伺服器的資料庫維護問題，我正在考慮索引片段。 代替需要耗費的時間，要找出每個索引的填滿因數，不就是只要將設定該執行個體的預設填滿因數的工作變得更容易嗎？ 是否有任何缺點作法吗？
**答：**我通常不建議設定填滿整個執行個體的因數為預設值以外，100%。 變更該設定可能會造成浪費的空間，在資料庫中。
當您在資料表上建立索引時，通常只有其中之一所會符合資料表插入模式。 所有其他索引無可避免地會變得分散。 只要插入模式僅能附加的 (不需要的隨機金鑰沒有隨機插入如全域唯一識別元 [GUID])，不要讓最大的索引分散的意義。
最大的索引永遠是叢集的索引中，因為叢集的索引是資料表。 這包含所有的資料表資料行的所有資料錄。 道理是不會取得分散的叢集索引。 從叢集索引中移除片段會較為昂貴 (的角度來看磁碟空間、 時間和交易記錄檔) 比這樣做的任何其他的索引。
因為叢集的索引通常並不會取得分散，因此合理的填滿因數設定為 100。 此作業需要任何額外的空間。 可能是因為其他原因的叢集的索引取得分散的 (例如從進行較長的時間資料表資料列的可變長度資料行)，但這通常是，則為 true。
如果您將整個執行個體的填滿因數設定為 100%以外的項目時，您必須特別設定的所有未取得分散的叢集索引 fillfactors。 如果不這麼做，他們會使用新的例項全填滿因數，並保留空間，當他們正在重建。 這基本上會浪費在資料庫中的空間。 您也可以這麼做，但它有通常不視為最佳作法。
有各種不同的任何資料庫中的索引，它有點不尋常，若要尋找單一填滿因數值，是最佳選擇所有的索引。 通常最好從管理角度來看，否則整個執行個體的填滿因數。 然後您可以只在需要的索引上特別設定較低的 fillfactors。
重新開機的回應
**問：**我們的環境中有些伺服器很少會重新開機。 雖然這是個好消息，在許多方面，它並不表示 SQL Server 錯誤記錄檔可以變得 impractically 大。 看來充滿數萬個我有沒有用的備份完成訊息。 是否有任何小、 更容易管理，讓錯誤記錄檔吗？
**答：**有兩件事，您可以： 剪下備份的郵件，然後設定錯誤記錄檔管理。 每次備份完成時，它會將錯誤記錄檔項目寫入。 這也沒什麼大用。 成功的備份完成是一定少不了，也就是不是錯誤的。
沒有記載的追蹤旗標--3226 追蹤旗標，便可制止備份成功訊息。 您應該將之加入至啟動追蹤旗標 (使用 SQL Server 組態管理員) 的清單。 若要啟用這沒有必須先停止並重新啟動 SQL Server，也開啟追蹤標幟使用命令"DBCC TRACEON 3226 (-1)。"若要套用的追蹤旗標-1 時表示。 SQL Server 小組有關追蹤旗標的 blogged 2007年中的上一步。
您也可以設定您的錯誤記錄檔管理 SQL Server Management Studio (SSMS) 中。 在 SSMS 中開啟物件總管並連接到 SQL Server。 展開 [管理] 方塊中的色彩、 SQL Server 記錄檔上按一下滑鼠右鍵，然後選取 [設定]。 設定的 SQL Server 錯誤記錄檔] 對話方塊出現時，請檢查 「 限制的錯誤記錄檔回收之前 」 的選項。 選取 99年錯誤記錄檔。 這會覆寫預設的六個保留的錯誤記錄檔數。
最後的設定步驟是什麼會限制每個錯誤記錄檔的大小。 指示建立新的錯誤記錄檔 (稱為 「 循環 」 錯誤記錄檔) 每日的 SQL Server。 做法是先建立每日的 SQL Server 代理程式工作，只是不會"EXEC sp_cycle_errorlog"。之後，您的錯誤記錄檔應該更容易管理。
有效駕馭 Tempdb
**問：**在過去兩年以來可大幅增長到我們的資料量。 我們的 tempdb 永遠看起來像是來填滿較推動才是。 讓我們做了許多的使用了暫存資料表，我們就會執行某些複雜的查詢。 您可以如何降低我們的 tempdb 使用量提供任何建議嗎？
A： Tempdb 的用法是 perennial 的 SQL Server 使用者問題。 沒有只有單一 tempdb 的每個 SQL Server 執行個體，因此您必須要很小心使用方式。
其中一個最常見的用法是 tempdb 的從暫存資料表。 這些資料表讓從複雜的彙總或聯結保存，並會變得更大的查詢部份的中繼結果。 通常，這可能是有效的方式來分割既長又複雜的查詢，但它並不一定大小寫。 有時候開發人員習慣使用預設的暫存資料表，而非進行任何效能測試，以查看使用暫存資料表更有效率。
建立暫存資料表中設定的中繼結果的問題在於此功能會中斷有效率的資料管線，到複雜的查詢。 它會強制查詢最佳化器處理暫存資料表建立或分開使用暫存資料表的後續作業的母體擴展。 如果沒有使用暫存資料表，有時候查詢最佳化器產生更有效率的查詢計劃。 它也可以執行更有效率地用不同的查詢建構，例如衍生的資料表或一般資料表運算式。
如果暫存資料表來分割您的查詢最有效率的方式，有兩件事，您可以如何降低 tempdb 使用量：
- 建立適當的索引： 請確定在暫存資料表上建立唯一的索引內容有實際作用來作進一步處理 (它會分析並檢查哪些索引查詢計劃所使用的核取)。 對每個暫存資料表資料行建立非叢集索引不太可能會很有用。 同時請確定填入暫存資料表中，因此有助於查詢最佳化器使用索引的統計資料之後，會建立索引。
- 暫存資料表大小降到最低： 請確定在唯一的資料行中保存暫存資料表是指用來進行進一步的處理，否則它們完成浪費的空間。 暫存資料表通常會建立具有 SELECT * 無以為哪些資料行，才能真正的建構。 如果您正在處理大型結果集，這些浪費的空間可以將會相當可觀。
不正確的備份
**問：**上週我們 SAN 損毀。 我們還是在實際執行資料庫中的部分資料遺失。 最新的備份儲存與資料庫檔案，一起 SAN 上，讓那些損毀。 我們還發現我們稍早的備份已損毀也 — 有時相同的損毀。 我們要如何避免在未來這種情況？
**答：**這是常見的情況 — 沒有良好的備份及單點失敗，最終會導致資料遺失。
第一個問題是您的備份已損毀。 您必須實作測試策略，您可以判斷備份已損毀，或包含損毀的資料庫備份。 有多個部分：
- 實作實際執行資料庫的定期的一致性檢查。 這表示執行 DBCC CHECKDB 命令本身的實際執行資料庫的複本。
- (如果尚未啟用)，請啟用頁總合檢查碼，在實際執行資料庫上。 請使用 WITH CHECKSUM 選項，所有的備份。 如要加入在備份中，有助於避免建立備份與損毀的資料庫讀取資料檔分頁，這將測試頁總合檢查碼。
- 備份的有效性檢查後實作它們執行。 這牽涉到另一個的 SQL Server 執行個體中進行備份和還原 (使用 WITH CHECKSUM 選項)，或至少在執行使用 WITH CHECKSUM 備份的還原 VERIFYONLY。 目標是要還原資料庫，然後執行 DBCC CHECKDB。 這也是適合用來卸載實際執行伺服器的一致性檢查工作負載。
- 實作您練習從可用的備份還原的實際執行資料庫的定期測試排程。
若要建立記錄傳送次要是另一種方法很容易地測試有效性的交易記錄檔備份。 這經常會從實際執行還原的交易記錄檔備份。 它也提供您的資料庫備份複本。
第二個問題是備份會儲存在相同的 I/O 子系統，與資料庫本身。 這表示您有任何保護措施 I/O 子系統失敗。
想要保留在不同的 I/O 子系統上的所有備份的複本，從實際執行資料庫 — 在理想的情況下，這會是完全不同的位置。 備份的本機複本協助更快速的嚴重損壞修復和遠端的複本會確保嚴重損壞修復是永遠都可能損壞或毀損區域儲存區時。
要考慮的另一項是令人覺得鼓舞一般的嚴重損壞修復切入。 假設已經侵襲損毀，並透過損毀修復計劃，以判斷其效益。我年 4 月 2011年篇文章中，"SQL Server： 保護資料的代價，"討論此主題管理觀點。
嚴重損壞修復的準備，就像安全性。 其中一個經常重複的指導方針是"防禦深度"。適用於修復及其他潛在的問題，您預期，並主動避免多個選項，就越可能可以修復嚴重損害您的停機時間和資料遺失的服務層級合約中。
.jpg)
**Paul s。 Randal**是 SQLskills.com、 Microsoft 地區 director 和 SQL Server MVP 管理的指導。 他在 1999 年 2007 年間服務於 Microsoft 的 SQL Server 儲存引擎 (SQL Server Storage Engine) 小組。 他所撰寫的 SQL Server 2005 的 DBCC CHECKDB/修復，並在 SQL Server 2008年開發期間主要是負責進行核心儲存引擎。 Randal 的專家嚴重損壞修復、 高可用性和資料庫維護，而且一般的簡報者在世界各地研討會發表演說。 他在 SQLskills.com/blogs/paul，而您的部落格可以找到他在 Twitter Twitter.com/PaulRandal。