SQL 線上問答：大小真的有差
資料庫大小、索引片段及容錯移轉後的可用性等，都是糾纏本月 SQL 系統管理員的當中幾個問題。
Paul S. Randal
恐懼的碎片
**Q。**我讀過幾個博客帖子，似乎意味著我們不需要擔心索引碎片，如果我們的資料庫中承載的固態存儲 — — 理論是固態驅動器 (策略性污水排放計畫） 是比旋轉磁片快很多。 我知道會減少性能下降，但是我們真的只是完全可以忽略索引碎片嗎？
**答：**不論你用旋轉磁片或.ssds，您需要注意索引碎片。 索引碎片包括兩種現象 — — 無序索引頁和頁密度問題。 前者防止高效閱讀未來在索引範圍掃描過程中和後者減少資料密度。
它是讀/寫延遲與策略性污水排放計畫確實很小。 因此，需要執行更頻繁、 更小預讀 I/o 範圍掃描碎片的索引不會有盡可能多的性能的影響，在同樣的情況在附近時使用旋轉磁片時。
然而，減少索引碎片從資料密度仍可以很大的問題。 大多數索引碎片時發生的操作稱為"頁拆分。"通過將一半的行的索引移動到新的一頁創建的索引頁上的可用空間時，將發生這種情況。 這使得大約 50%的空白空間的舊的和新的頁面。 碎片索引，它不是不尋常的請參閱索引頁面平均密度的 70%或更少 （有 30 ％ 的可用空間）。
這一點，如果索引資料庫存儲在您的策略性污水排放計畫中的一大批具有密度低的頁，這意味著您昂貴的策略性污水排放計畫可能需要存儲大量的空白空間。 這顯然不是最優的情況。 此外，即使在低密度頁中讀取所需的額外 I/o 將策略性污水排放計畫具有低延遲，他們會佔用更多的空間，在 SQL Server 緩衝集區 （記憶體中的資料檔案頁面緩存） 中。 這也意味著您寶貴的伺服器記憶體不得到最佳的利用。
另一個需要考慮索引碎片本身除了是碎片的原因：頁拆分。 這些都是昂貴產生大量的事務日誌記錄的操作 （看一看我篇博客文章來看看這是多麼糟糕）。 這些額外的日誌記錄的事務日誌中讀取的任何意味著額外的處理 （例如，事務性複製、 備份、 資料庫鏡像，日誌傳送）。 這可能會導致性能下降，這些相同的過程。 所以不要忽略索引碎片，只是因為您使用的策略性污水排放計畫。
別看著鏡子
**Q。**我們想要重新設計我們的可用性策略，但已被卡住了，如何使幾個事務性複製訂閱資料庫更高度可用。 我們不能使用資料庫鏡像對 SQL Server 2005，因為我們將不得不重新初始化訂閱後容錯移轉。 現在，我們對 SQL Server 2008 R2，是否有更好的解決方案嗎？
**答：**你正確地指出只鏡像訂閱資料庫的 SQL Server 2005 提供了已經被鏡像到訂閱資料庫的鏡像副本的資料的冗余副本。 沒有方法來重新創建複製沒有完成重新初始化訂閱。 很明顯，這使得資料庫鏡像對 SQL Server 2005 的一個糟糕的選擇。
SQL Server 2008 中，有一種新的機制引入，它允許部分重新初始化訂閱的事務性複製。 該選項被稱為"從 lsn 初始化"。當調用 sp_addsubscription 時，它被指定為 @ sync_type 參數。
允許您添加和刪除節點端對端拓撲中，而無需進行的所有活動拓撲中完全靜止首先加強了 SQL Server 2008 中的對等事務性複製。 這是一個主要提供資料可用性-點對點拓撲結構，提高了。 "從 lsn 初始化"選項添加了這些增強功能是出在地方。
對於資料庫鏡像時，沒有更多的支援，用於鏡像的訂閱資料庫 （如鏡像發佈資料庫的日誌讀取器代理中有）。 但是，您可以使用"從 lsn 初始化"方法提供快速重新初始化訂閱後鏡像容錯移轉。
這種方法依賴于確定日誌序號 (LSN — 標識事務日誌記錄的唯一編號） 最近的複製操作應用到訂閱資料庫鏡像容錯移轉發生之前。 我們會打電話給此 LSN2。
某些操作會有也被鏡像到資料庫的鏡像副本發生容錯移轉之前。 這可以去 LSN3，例如，有點進一步在時間比 LSN2。 也有一些尚未在所有應用到訂閱資料庫的操作。 這些都是最近的時間比 LSN2 或 LSN3。 我們會打電話給那些 LSN1。
高達 LSN2 的所有操作都應用於主要的訂閱資料庫。 達 LSN3 的所有操作都在主要的訂閱資料庫中的應用和鏡像到鏡像訂閱資料庫。 若要執行"從 lsn 初始化"初始化的新的訂閱鏡像容錯移轉後，對 sp_addsubscription 的調用必須使用 LSN3 作為起始點。
分佈保留的時間也必須設置這樣操作在分發資料庫中保留一段時間後他們已經被應用到訂閱資料庫。 簡而言之，您現在可以使用資料庫鏡像提供僅鏡像容錯移轉後所需最小重新初始化訂閱資料庫的高可用性。 下載白皮書，這更多更深入的解釋，"SQL Server 複製：提供高可用性使用資料庫鏡像。"
太大了，控制碼
**Q。**我們的主要資料庫已達到近 9TB。 我們發現我們只是沒有不嚴重影響了我們正常的工作負載的情況下執行定期維護任務的能力。 我們最關心的問題能夠備份資料庫，以允許進行災難恢復。 您有什麼建議嗎？
**答：**這是分裂成更易於管理的塊的資料庫會有好處。 您可以通過多種方式，最常見的使用 SQL Server 表/索引分區 （企業版） 中的新功能或手動劃分到單獨的表中。
在任一情況下，關鍵的一點是在資料庫中創建多個檔組。 分區後，大表/索引的每個分區駐留在單獨的檔組中。 與手動分裂，每個大表駐留在單獨的檔組 （可能與所有以及其索引）。
通過使用單獨的檔組，您有了更精細的單位，可以備份和還原的資料庫。 您不必在每次對整個 9TB 操作。 如果你有一個銷售的資料庫，例如，從 2012 年起回 2008 年的資料可以表進行分區的各種資料區域的成日曆年分區。 一年中的每個分區將在單獨的檔組中。
僅 2012年檔組正在進行更改，您可以備份它經常。 要少得多，您可以備份其他不變的檔組。 這節省了備份存儲空間和生產系統上的招致額外 I/O 開銷的執行備份的時間量。
這樣的安排，災難恢復也會變得更快 （使用企業版）。 您只需要快速還原將線上工作負載的連線交易處理 (OLTP) 部分所需的檔組。 您可以使用部分還原，執行此操作，然後使用部分資料庫可用性使資料庫線上。 您可以還原的檔組包含稍後使用線上逐段還原，雖然已經線上檔組中出現的 OLTP 活動較舊的資料。
你可以閱讀更多關於這方法在這些白皮書：
在壓力下
**Q。**一件事混淆了我們的 DBA 團隊是如何判斷是否緩衝集區迫。 有很多衝突有關的資訊的效能計數器和使用什麼閾值。 我讀過的最說使用頁面壽命 (PLE) 和 300 作為閾值。 一些對此可以闡明你嗎？
**答：**你不是獨自在你的困惑。 五年前發表的一份微軟白皮書中首次引用數 300。 這就是現在嚴重過時。
PLE 櫃檯使用，但你必須明白它的意思，何時保持有關。 這一數位提供的緩衝集區如何積極作出所需的資料檔案頁面從磁片讀取到記憶體空間的即時措施。 它不是平均值。 它是預計的時間，以秒為單位的頁讀取從磁片將留在記憶體之前您需要刷新它出另一個頁面可以取代它。
為此，看單個 PLE 值不能很好。 你要看看價值取向。 它是完全有可能導致大幅下降到 PLE 有效 SQL 伺服器的操作。 它常常然後將會恢復到其以前的值。 如果 PLE 下降，並且處於低位，這是令人關注。
閾值時，將有關不是一個固定的值，像許多人形容。 300 值意味著整個緩衝區池正在更換每 300 秒。 如果你有 100 GB 緩衝集區，例如，這意味著 100 GB 的新資料被讀取到記憶體中每隔五分鐘。 這顯然是一個性能問題。 然而，它變得 PLE 來臨 300 之前大規模性能問題方式。 您可以計算出更合理的值使用 （緩衝集區記憶體中 GB / 4) * 300，如所述這篇文章。
此外，您還需要瞭解非一致性記憶體訪問 (NUMA) 配置您的伺服器。 PLE 計數器在緩衝區管理器效能物件是實際上的廟宇，對於每個 NUMA 節點，平均值，如果您已配置的 NUMA。 這意味著緩衝區管理 PLE 監測並不是真正的伺服器上的記憶體壓力指標。 在這種情況下，您應測量 PLE 計數器中每個緩衝區分區的效能物件。 您可以閱讀更多有關 PLE 和在 NUMA 本博客。
PLE 櫃檯來監視，但您只應關注如果值顯著低於正常，並且長時間留在那裡。 這是一般的指引，但不幸的是，不會有任何適用于所有情況的具體細節。
.jpg)
**Paul S. Randal**是的董事總經理 SQLskills.com，微軟的區域主任和 SQL 伺服器 MVP。 他在 SQL Server 存儲引擎團隊在微軟從 1999 年到 2007 年。 他寫道： 為 SQL Server 2005 的 DBCC CHECKDB/修復，在 SQL Server 2008 的開發過程中負責核心存儲引擎。 Randal 是災難恢復、 高可用性和資料庫維護方面的專家，也是經常在世界各地的會議簡報者。 在他的博客 SQLskills.com/blogs/paul，你可以找到他在 Twitter 上和 twitter.com/PaulRandal。