維護 SQL Server 環境可能是一項非常複雜的任務。您可以通過本文提供的十種方式來降低複雜性並減輕壓力。
原作者：Paul S.Randal
過去數年來，許多公司紛紛精簡了其 IT 部門。很多資料庫管理員 (DBA) 不得不承擔大量的 SQL Server 資料庫管理工作。更糟糕的是，往往公司內部沒有真正有經驗的 DBA，而是隨便找個人來充任。而且有時候，DBA 純粹成了救火隊員，在不斷湧現的危機之間疲於奔命。這樣惡劣的環境是不正常的，也難以持久。沒有人願意處於這種持續壓力和干擾之下。
擺脫這種境況的一個方法是花點功夫來簡化您的 SQL Server 環境，使之更易於理解和管理。作者根據擔任 SQL Server 顧問的實際經驗總結出了以下十種方式，可以清楚的讓 SQL Server DBA 提高對環境的控制力，並減少發生危機的可能性。這些方式按大致的重要程度列出，越往後越重要。
10.編制清單
有多少次當您被要求還原受損的資料庫資料時，您甚至不知道這些資料的存在？SQL Server 資料庫很容易在公司內氾濫。DBA 團隊可能不知道資料庫中哪些資料不在了，從而失去對 SQL Server Instance的控制。這樣一來，未進行備份、修補的資料庫可能無法採取恰當的保護，並錯失其他很多必要的管理任務。
因此，當務之急是掌握您可控制的公司Instance和資料庫最新清單。這可以讓你有效的管理它們、必要時進行合併，並正確劃定範圍和規劃專案及升級的唯一途徑。編制清單還可以讓您在與公司內各個團隊協商之後，公佈您負責的已知Instance清單來明確您的職責。您可以擬定已知Instance的支援策略，並要求新Instance嚴格遵守您的配置準則，否則將不予支援。
有許多工具可以讓您創建 SQL Server 清單，例如，像 SQLPing3 和 SQLRecon 這樣的簡單工具、Microsoft 評估和計畫工具包含 Quest Discovery 嚮導等。
9.標準化配置
如果您負責的資料庫和 SQL Instance數量在不斷增長，您會發現不同配置的數量也在以類似的方式增長。如果您不得不記住不同Instance的配置細節，那麼很難在面對不同Instance時取得較佳的效能。
解決方法是盡可能標準化配置資訊，如磁碟機代號、伺服器配置選項、資料庫設置、資料庫維護、安全設置等等。SQL Server 2008 中引入了基於策略的管理功能，可以定義和實施策略。此外，Microsoft 的 SQL Server 技術專家 Lara Rubbelke 開發出了企業策略管理 (EPM) 框架，可輕鬆擴展到 SQL Server 2005 和 SQL Server 2000 Instance上。您可以從 CodePlex 獲取該 EPM 框架。圖 1 顯示了一個 EPM 框架報告示例。
8.瞭解 I/O 子系統
有幾個與 I/O 子系統有關的因素會對 SQL Server Instance造成影響。您需要認識到這些因素及其可能的影響：
I/O 子系統的讀/寫輸送量和磁碟空間容量。必須能滿足工作負荷峰值要求，並能在您不得不為增長的資料量購買更多容量之前提供足夠的空間。您可以分析並確定 I/O 瓶頸並將資料或日誌檔移至 I/O 子系統的其他部分，從而更均勻地平衡負載。
I/O 子系統可以透過RAID的機制執到資料保護的作用。保護好資料和日誌檔，避免因驅動器故障和其他潛在問題而遭受損失是很重要的。但這往往要進行折衷 - RAID-10 的冗余能力勝過 RAID-5，價格也更昂貴。有關詳細指南，請參見白皮書 “物理資料庫存儲設計”。
I/O 子系統的 RAID 等級、NTFS 分配單元/簇大小和分區對齊是否配置正確。有關詳細資訊，請查看作牙Ｄ的博客帖子 “Are your disk partition offsets, RAID stripe sizes, and NTFS allocation units set correctly?"。
PS:對於儲存架構的部份，也可以參考我的另一篇文章，SQL Server 儲存設備 (Storage) 最佳調整作業。
7.創建自訂維護計畫
作者在教授資料庫維護課程時，總是以“你不能只是把資料庫付諸生產，然後聽之任之”作為開頭語。索引會隨時間變得越來越零碎，從而導致性能降低。統計資訊逐漸過時，從而導致不良查詢和惡化的性能。I/O 子系統可能遭到破壞，對備份的需求永無止境。
您可以為資料庫定制一個全面的維護計畫，來解決以上所有問題。自訂的計畫遠比不能充分滿足需求的通用計畫好得多。作者曾于 2008 年 8 月在《TechNet 雜誌》上發表了 “高效維護SQL Server 資料庫的關鍵技巧” 一文，其中介紹了如何創建好的維護計畫。建立自己的維護計畫的最佳開始方式是使用 Ola Hallengren 編寫的免費腳本。作者極力推薦大家使用該腳本。
6.確保系統安全性
花點時間主動發現安全問題是很有必要的，可以防止事件發生，而不用事後再做處理。作者的另一篇《TechNet 雜誌》文章，“常見的 SQL Server 安全性問題和解決方案”，列出了十個最常見的安全問題以及規避方法。此外，發現漏洞時別忘了及時修補系統。
5.處理好與開發團隊的關係
在任何 IT 部門中，DBA 團隊與開發團隊之間的關係往往是主要矛盾之一。這兩個團隊通常都不理解對方的優先事項和關注點 - 從開發時期到 SQL Server 設計決策。在行為、性能問題以及部署與支援職責等方面，兩個團隊常常持不同觀點。
您可以通過積極而有效地參與開發團隊的工作來使自己的任務進展更順利。共同組織教育課程是一種頗為奏效的方式，尤其是當氣氛很友好時。在將設計付諸生產之前，與出席的 DBA 團隊成員一起進行評審並充分測試代碼，這有望避免可能進一步有損團隊關係的破壞性錯誤。
4.制定全面的災難恢復策略
無論您的基礎結構有多牢固，當災難降臨時您必須具備應急計畫。您無法預知損壞、停電、火災、意外資料丟失或其他諸多潛在問題，因此，您需要一個計畫來應對這些問題並進行恢復。
您可以和管理層一起擬定資料庫的停機時間及資料遺失補救策略，對如何從各種資料丟失類型中恢復做出規劃，並確定如何將資料庫和所有 SQL Instance納入公司的業務連續性計畫。弄清楚所有資料庫和Instance的相對重要性，以便確定災難恢復的優先次序。
您還需要借助其他技術來說明瞭解問題發生的時間，例如，頁面校驗、一致性檢查、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 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) 與他聯繫。
沒有留言:
張貼留言