SQL Server：SQL Server 專家的十個秘密

  • 發行項

維護 SQL Server 環境可能是一項非常複雜的任務。 您可以通過本文提供的十種方式來降低複雜性並減輕壓力。

Paul S.Randal

過去數年來，許多公司紛紛精簡了其 IT 部門。 很多資料庫管理員 (DBA) 不得不承擔大量的 SQL Server 資料庫管理工作。 更糟糕的是，經常並沒有真正意義上的 DBA，而是隨便找個人來充任。 而且有時候，DBA 純粹成了救火隊員，在不斷湧現的危機之間疲於奔命。 這樣惡劣的環境是不正常的，也難以持久。 沒有人願意處於這種持續壓力和干擾之下。

擺脫這種境況的一個方法是花點功夫來簡化您的 SQL Server 環境，使之更易於理解和管理。 我根據擔任 SQL Server 顧問的實際經驗總結出了以下十種方式，可以説明 SQL Server DBA 提高對環境的控制力，並減少發生危機的可能性。 這些方式按大致的重要程度列出，越往後越重要。

**10.**編制清單

有多少次當您被要求還原受損的資料庫資料時，您甚至不知道這些資料的存在？SQL Server 資料庫很容易在公司內氾濫。 DBA 團隊可能不知道資料庫中哪些資料不在了，從而失去對 SQL Server 實例的控制。 這樣一來，未進行備份、修補的資料庫可能無法採取恰當的保護，並錯失其他很多必要的管理任務。

因此，當務之急是掌握您可控的公司實例和資料庫最新清單。 這是有效管理它們、必要時進行合併，並正確劃定範圍和規劃專案及升級的唯一途徑。 編制清單還可以説明您在與公司內各個團隊協商之後，通過公佈您負責的已知實例清單來明確您的職責。 您可以擬定已知實例的支援策略，並要求新實例嚴格遵守您的配置準則，否則將不予支援。

有許多工具可以説明您創建 SQL Server 清單，例如，像 SQLPing3 和 SQLRecon 這樣的簡單工具、Microsoft 評估和計畫工具包和 Quest Discovery 嚮導等。

**9.**標準化配置

如果您負責的資料庫和 SQL 實例數量在不斷增長，您會發現不同配置的數量也在以類似的方式增長。 如果您不得不記住不同實例的配置細節，那麼很難在面對不同實例時取得高效。

解決方法是盡可能標準化配置資訊，如磁碟機代號、伺服器配置選項、資料庫設置、資料庫維護、安全設置等等。 SQL Server 2008 中引入了基於策略的管理功能，可説明定義和實施策略。 此外，Microsoft 的 SQL Server 技術專家 Lara Rubbelke 開發出了企業策略管理 (EPM) 框架，可輕鬆擴展到 SQL Server 2005 和 SQL Server 2000 實例上。 您可以從 CodePlex 獲取該 EPM 框架。 圖 1 顯示了一個 EPM 框架報告示例。

The Enterprise Policy Management Framework report

圖 1 企業策略管理框架報告

**8.**瞭解 I/O 子系統

有幾個與 I/O 子系統有關的因素會對 SQL Server 實例造成影響。 您需要認識到這些因素及其可能的影響：

  • I/O 子系統的讀/寫輸送量和磁碟空間容量。 必須能滿足工作負荷峰值要求，並能在您不得不為增長的資料量購買更多容量之前提供足夠的空間。 您可以確定 I/O 瓶頸並將資料和/或日誌檔移至 I/O 子系統的其他部分，從而更均勻地平衡負載。
  • I/O 子系統的 RAID 級別冗余能力以及能否執行諸如分割鏡像備份的操作和任何形式的鏡像/複製（在 I/O 子系統層面，而非 SQL Server 層面）。 保護好資料和日誌檔，避免因驅動器故障和其他潛在問題而遭受損失是很重要的。 但這往往要進行折衷 - RAID-10 的冗余能力勝過 RAID-5，價格也更昂貴。 有關詳細指南，請參見白皮書“物理資料庫存儲設計”。
  • I/O 子系統的 RAID 條帶大小、NTFS 分配單元/簇大小和分區對齊是否配置正確。 有關詳細資訊，請查看我的博客帖子“Are your disk partition offsets, RAID stripe sizes, and NTFS allocation units set correctly?（您的磁盘分区偏移量、RAID 条带大小和 NTFS 分配单元设置是否正确？）”。

**7.**創建自訂維護計畫

我在教授資料庫維護課程時，總是以“你不能只是把資料庫付諸生產，然後聽之任之”作為開頭語。 索引會隨時間變得越來越零碎，從而導致性能降低。 統計資訊逐漸過時，從而導致不良查詢和惡化的性能。 I/O 子系統可能遭到破壞，對備份的需求永無止境。

您可以為資料庫定制一個全面的維護計畫，來解決以上所有問題。 自訂的計畫遠比不能充分滿足需求的通用計畫好得多。 我曾于 2008 年 8 月在*《TechNet 雜誌》*上發表了“高效维护 SQL Server 数据库的关键技巧”一文，其仲介紹了如何創建好的維護計畫。 建立自己的維護計畫的最佳開始方式是使用 Ola Hallengren 編寫的免費腳本。 我一直推薦客戶使用該腳本。

**6.**確保系統安全性

花點時間主動發現安全問題是很有必要的，可以防止事件發生，而不用事後再做處理。 我的另一篇*《TechNet 雜誌》*文章，“常见的 SQL Server 安全性问题和解决方案”，列出了十個最常見的安全問題以及規避方法。 此外，發現漏洞時別忘了及時修補系統。

**5.**處理好與開發團隊的關係

在任何 IT 部門中，DBA 團隊與開發團隊之間的關係往往是主要矛盾之一。 這兩個團隊通常都不理解對方的優先事項和關注點 - 從開發期限到 SQL Server 設計決策。 在行為、性能問題以及部署與支援職責等方面，兩個團隊常常持不同觀點。

您可以通過積極而有效地參與開發團隊的工作來使自己的任務進展更順利。 共同組織教育課程是一種頗為奏效的方式，尤其是當氣氛很友好時。 在將設計付諸生產之前，與出席的 DBA 團隊成員一起進行評審並充分測試代碼，這有望避免可能進一步有損團隊關係的破壞性錯誤。

**4.**制定全面的災難恢復策略

無論您的基礎結構有多牢固，當災難降臨時您必須具備應急計畫。 您無法預知損壞、停電、火災、意外資料丟失或其他諸多潛在問題，因此，您需要一個計畫來應對這些問題並進行恢復。

您可以和管理層一起擬定資料庫的停機時間及資料丟失軟體授權合約，對如何從各種資料丟失類型中恢復做出規劃，並確定如何將資料庫和所有 SQL 實例納入公司的業務連續性計畫。 弄清楚所有資料庫和實例的相對重要性，以便確定災難恢復的優先次序。

您還需要借助其他技術來説明瞭解問題發生的時間，例如，頁面校驗和、一致性檢查、SQL 代理警報和 System Center Operations Manager 警報等。 災難恢復基礎結構可通過備份、日誌傳送、複製和資料庫鏡像來説明您保護資料，並有可能通過資料庫鏡像或容錯移轉群集將容錯移轉到冗余系統上。 以下兩個 Microsoft 白皮書可為您提供説明：“High Availability with SQL Server 2008（SQL Server 2008 高可用性）”和“Proven SQL Server Architectures for High Availability and Disaster Recovery（具备高可用性和灾难恢复功能的经检验的 SQL Server 体系结构）”。

**3.**定期備份並進行測試

無論您的高可用性和災難恢復計畫有多周詳，您都必須對資料庫進行定期備份。 如果您的資料庫遭到破壞或滅頂之災，那麼您唯一的資源或許只有最後的備份，倘若您沒有任何備份，可能會給公司帶來極其嚴重的後果。 您不僅需要備份，還需要定期進行恢復測試，以保證這些備份在需要時能夠正常使用。

您可以從我 2009 年為*《TechNet 雜誌》*撰寫的兩篇文章中找到更多資訊：“Understanding SQL Server Backups（了解 SQL Server 备份）”和“SQL Server:Recovering From Disasters Using Backups（SQL Server：使用备份进行灾难恢复）”。

**2.**監視和維護性能

性能調節佔據了 DBA 的大部分時間，但有很多方法可以簡化這個過程：

  • 建立性能基準，以便了解性能是否真的發生了變化。
  • 將系統分解為可在無外部因素干擾下隔離測量的基元。
  • 使用等待-排隊方法快速查明性能問題。
  • 採用系統基元、效能計數器監視性能，並等待統計資訊。 這樣您會知道性能何時開始下降。 可使用 SQL Server 2008 中的性能資料收集器功能以及 SQL Server 2005 的性能儀錶板。
  • 制定維護計畫。
  • 借助工具認真規劃和執行索引策略，如資料庫引擎優化顧問、DTA、缺失索引動態管理視圖 (DMV) 和索引使用 DMV。

**1.**懂得從何處尋找資訊

要做的事情無窮無盡，懂得何時放手並尋求説明才是上上之策。 您應當瞭解自己的局限性，清楚自己不可能瞭解有關 SQL Server 的一切。 如果有人能説明您完成任務或解決問題，那麼您沒有必要自己苦苦掙扎並浪費寶貴的時間。

您的首要 SQL Server 資訊源是 SQL Server 联机丛书，您可以下載並安裝到本地，或在 MSDN 中連線搜索。 《SQL Server 連線叢書》很適合用來查詢語法，但如果你有更複雜的操作問題，或正嘗試解決某個問題，那麼最好的辦法是將問題發佈到連線論壇。 MSDN 上有許多 SQL Server 論壇，還有一些熱門的社區網站，如 SQL Server Central。

還有一種尋求説明的快速方式是借助 Twitter 的 SQL Server 社區。 發佈問題時加上 #sqlhelp 雜湊標籤，很多 SQL 專家（包括我）便可以看到您的問題。

此外，可以參加專門討論 SQL Server 的會議，例如，每年的 PASS 社區峰會、兩年一次的 SQL Server Connections 或更頻繁的 SQL 星期六主題日。 可以關注社區中很多 SQL Server 專家的博客。 您可以通過 MVP Thomas LaRock 維護的博客排名，瞭解這些博客的活躍程度及關注價值。

您可能已經因工作強度過大而不堪重負，但如果能抽出一些時間來瞭解這些建議，您會發現自己獲益匪淺。 您的系統將運行得更順暢，您將更有條理，您將獲得更多的寧靜 - 您終將成為一名更為專業的 DBA。

Paul Randal

**Paul S.**Randal是 SQLskills.com 的常務董事、Microsoft 區域總監和 SQL Server MVP。從 1999 年到 2007 年，他一直在 Microsoft 的 SQL Server 存儲引擎團隊工作。他曾編寫過 DBCC CHECKDB/repair for SQL Server 2005，並在 SQL Server 2008 的開發過程中負責核心存儲引擎部分的工作。Randal 是災難恢復、高可用性和資料庫維護方面的專家，經常在全球出席一些會議。您可以訪問他的博客 SQLskills.com/blogs/paul，也可以通過 Twitter (Twitter.com/PaulRandal) 與他聯繫。

相關內容