Share via

  • 發行項

SQL Q & A 移除索引片段，與同步處理同步處理及其他資訊

Paul S. Randal

Q我是哪一張如何移除索引片段會影響統計資料。 我聽說，有時候，我應該重建我後重建索引的統計資料，但有時候我應該且重新建立叢集的索引會影響所有其他索引太。 我要確定我不小心讓效能更嚴重，可以 shed 這個請某些指示燈嗎？

A這當然會是會造成許多困惑的問題，但您是對一個完整的資料庫的維護策略包括移除索引片段中，並更新統計資料。 我不打算進入完全何時和為何来移除索引片段的詳細資料 (如，請參閱 8 月 2008 文件 」 最有效的資料庫維護秘訣." 而，我假設您知道它要使用的索引，我將只專注於項目的運作方式。

第一個部分，混淆的會是周圍的分散程度的移除作業會影響統計資料。 重建索引 (使用 ALTER INDEX … 重建，DBCC DBREINDEX 或 CREATE INDEX … WITH DROP_EXISTING) 不會更新統計資料與相等的一個完整的掃描但重新組織 (使用 ALTER INDEX … 重新組織或 DBCC INDEXDEFRAG) 的索引不會更新統計資料完全，即使兩者都移除索引片段。

重建不會更新統計資料，重新組織不原因的使用，用於這些作業的演算法。 索引重建作業有完整的索引檢視並因此可能會更新統計資料正確。 「 重新組織 」 作業，只能一次作業索引的一些網頁但無法正確地更新整個索引統計資料。

第二個部分，混淆的會是哪些更新統計資料時重建索引。 有兩種一般資料表的統計資料) 的資料表的索引資料行和非索引資料行。 索引重建作業只會更新正在重建索引的統計資料。 非索引的資料行統計資料必須以手動方式更新，維護計畫中。 此外，「 最有效的資料庫維護秘訣 」 文件中所提到，您必須小心不要手動更新可能會使用資料取樣率小於 100%的而在索引重建會使用完整掃描 (100) 範例的對等用法，手動更新索引的統計資料後重建的索引。 也就是說，這導致覆寫的取樣的統計資料的完整掃描的統計資料。

在產生混淆，最後一個部分會是重建索引有什麼影響周圍有其他的索引。 答案是永遠的重建索引只影響該特定的索引和其統計資料。 例外狀況是，重新建置這類的索引也會導致所有非叢集索引重建資料表的 SQL Server 2000 中的非唯一叢集索引。 這已經修正從 SQL Server 2005 開始遞增編號。 您可以找到更多的資訊，這個點上，在我的部落格張貼 」 從每個角度的索引."

總而言之，您索引和統計資料的維護應該執行下列：

  • 重建或重新組織您的索引，要移除分割
  • 更新索引的統計資料，無法重建這些索引
  • 更新非索引的統計資料

Q我已經實驗的 SQL Server 2008，並我已經發現某些怪異行為]。 看來如果我啟用資料壓縮，在實際執行資料庫中的並再備份資料庫而嘗試將它還原在 Standard Edition 執行個體上，會還原失敗! 此預期的行為？ 如果，則是此限制資料壓縮] 或 [會影響任何其他的功能？ 而且為什麼不還原失敗立即代替 seeming 進行整個還原之前失敗？

A您所看到的行為是設計中。 最 「 企業-僅 」 功能只會限制 SQL Server，您可以進行的版本使用的 Enterprise Edition、 Enterprise Evaluation Edition，和 Developer Edition 功能。 有一些功能，但是，也限制哪個 SQL Server 版本可以還原資料庫包含 「 」 功能的備份。 您已經找到其中一個 SQL Server 2008 功能有這項限制 — 資料壓縮。

行為是實際上不是新的 SQL Server 2008。 在 SQL Server 2005，如果資料庫包含任何分割資料表或索引 (明確地使用分割的功能) 的資料庫的備份可以只使用還原的版本在清單中，然後我剛才提到。 有兩個問題這，但是，SQL Server 2005 中。 首先，很難辨別是否沒有一個的資料庫任何磁碟分割，並在第二，還原不失敗，直到只會有完成之前。

這表示您不瞭解您還原將失敗，直到您已等候透過整個 (可能長期執行) 還原作業。 這是因為資料庫不是交易的一致性，直到完成復原還原部分)，所以在修復期間的作業中可能新增或移除磁碟分割。 遇到這種情況下可以是真的討厭在嚴重損壞修復情況下，唯一可以快速取得還原資料庫的伺服器剛好是 Standard Edition。

在 SQL Server 2008 中, 與此表現方式的 「 企業-僅 」 功能的清單增長到四個： 資料壓縮、 變更資料擷取、 透明化的資料加密，和磁碟分割。 這表示更多人將會遇到這個問題。 基於此理由新的 DMV 已加入，讓 DBA，輕鬆地檢查這些功能是否已啟用在資料庫的 sys.dm_db_persisted_sku_features。

執行個體，在資料庫的資料表已啟用資料壓縮，執行 [DMV 會提供下列結果：

SELECT * FROM sys.dm_db_persisted_sku_features;
GO
feature_name    feature_id
--------------  -----------
Compression     100

不過，SQL Server 2008 無法解決問題，與在還原作業幾乎完成之前，DBA 會通知實際上無法還原資料庫。 事實，這個問題不太可能注意指定如何的本質還原的運作方式 (請參魷 \ cs6 \ f1 \ cf6 \ lang1024， SQL 問題與解答的資料行從 10 月 2008 問題 如需詳細資訊。

如果的可能需要 Standard Edition (或較低的版本) 上還原資料庫的必要 DBA 是不允許這些功能或使用 [DMV 定期以避免在重要的情況下還原時，取得難處理的意外。

Q我已實作同步的資料庫鏡像，並下，這表示永遠與主體資料庫同步處理鏡像資料庫，認為是。 不過，我偶爾會看到鏡像狀態變成 SYNCHRONIZING 代替 SYNCHRONIZED，以及當我們先設定鏡像。 為什麼這發生？

A之前我回答的問題先我會定義 SYNCHRONIZED 和 SYNCHRONIZING 資料庫鏡像狀態。 總而言之，資料庫鏡像的運作方式，藉由持續傳送裝載主體資料庫的 SQL Server 執行個體] 和 [主控鏡像資料庫執行個體之間的實體的交易記錄檔記錄。 如果沒有交易記錄檔記錄，等待傳送到鏡像原則同步處理鏡像的狀態 (也就是說，兩個資料庫是在同步)。 如果有交易不尚未被傳送到鏡像 (鏡像資料庫是 「 後面 」 主體) 的記錄，鏡像的狀態會是 SYNCHRONIZING。

初始化資料庫鏡像，方法是取得完整的資料庫備份，加上至少一個交易記錄檔備份，並還原它們 (使用 WITH NO_RECOVERY) 鏡像上。 然後啟用鏡像時，是一開始同步鏡像的狀態。 這是因為可能會有一些交易活動在主體上自上次上鏡像已還原的記錄檔備份之後。 這是很有可能使用常數的工作負載資料庫。

此技巧來降低嘗試進行可能使用為最新的鏡像資料庫鏡像進行同步處理的狀態停留在時間記錄檔備份。 不過，常數的工作負載的資料庫，這可能會非常困難，並因此鏡像狀態一開始會 SYNCHRONIZING 一段時間。 一旦設定攔截的鏡像，SYNCHRONIZED 將變更鏡像的狀態。

之後, 它有可能一次會落後的主要中, 鏡像狀態的情況下將放上一步到 SYNCHRONIZING 鏡像資料庫。 如果主體與鏡像就無法通訊一段時間，可能是造成這個問題的原因之一。 或可能發生這種情況如果主體不是記錄檔可以傳送到鏡像的速度產生交易記錄檔。 不論是哪的種情況，及視如何設定資料庫鏡像，主體資料庫可能會繼續處理交易和記錄將會建置 (稱為傳送) 佇列) 的交易記錄檔的佇列。 這必須是傳送至鏡像中，才能設定攔截。 直到鏡像資料庫已設定攔截到的鏡像的狀態將會保留 SYNCHRONIZING。

網路連結不可靠的主體和鏡像之間是否您可能會看到 Back-和-之間切換 SYNCHRONIZING] 及 [SYNCHRONIZED 鏡像的狀態。 您可以在白皮書中找到這些狀態的完整討論 SQL Server 2005 中的鏡像的資料庫.

Q我們有同步的資料庫上，我們的主應用程式資料庫的鏡像處理設定]，並我們監視會顯示鏡像上的重做佇列是通常附近的零。 我們想要使用鏡像資料庫報告，以及一致性檢查，因此我們可以讓更好使用多餘的硬體。 我們知道這是可能，但會有如此，我們應該知道的任何缺點呢？

A 這是很常見的作法是，但有一些缺點，您可能需要注意的]。

第一個問題授權。 為 SQL Server 執行個體裝載鏡像資料庫 License 是如果執行個體只會用於該目的可用的。 只要您在鏡像資料庫上建立資料庫快照集，或執行任何動作與該 SQL Server 執行個體，您必須購買授權。

一致性檢查是攸關 (透過資料庫的快照集) 在鏡像資料庫上執行它們不會提供任何保證主體資料庫的一致性。 只交易記錄檔記錄的鏡像處理的資料庫之間所以鏡像如果 I / O 子系統損毀的主體資料庫中的頁面的損毀將不被處理鏡像資料庫上。 這表示，請鏡像資料庫的一致性檢查會無法參閱的損毀網頁主體的資料庫。

報告，是良好的資料庫鏡像用法。 人員會執行到的第一個問題是： 如何重新整理報告執行對資料庫快照集。 無法更新快照集，因此必須建立一個新的快照集資料庫和報告應用程式必須連接至新的快照集) 中。 這需要額外的邏輯內建的報告應用程式。 第二個問題決定如何報告應用程式應有的行為鏡像容錯移轉的事件 — 應該它保持連接到新的主體，或將它應該移至新的鏡像？ 進行到詳細資料，這已超出本文的範圍中。

鏡像資料庫的任何額外的使用，主要的考量是潛在的鏡像上造成效能問題。 建立資料庫快照集將加入額外的 I / O 負載，第一次頁面變更鏡像資料庫，它必須被推入資料庫快照集。 而且，然後將資料庫快照集的任何工作負載會增加 I / O 負載，鏡像資料庫上的，許多讀取資料庫快照集的頁面會真的會讀取從鏡像資料庫，它們將不會有變更快照集建立後。

這個額外的 I / O 負載，鏡像資料庫上可以降低重新在顯示交易記錄檔記錄並依序至積存的負責人。 這個積存會稱為重複佇列，而且是之前鏡像資料庫可以上線在容錯移轉後必須重新顯示交易記錄檔的數量。 大 I / O 負載，鏡像資料庫，從資料庫快照，大重複佇列將可能成長和長資料庫將無法在容錯移轉後使用。

您沒有提到所以可能無法為您的問題，但它是絕對有注意讓您不最後危害資料庫的可用性的多多增加能夠執行報告您的取消復原佇列長度已是通常附近的零。

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您可以找到他在 Twitter Twitter.com/PaulRandal.