sql server dba大牛的祕籍

維護SQL Server環境可能是一個很複雜的工作（如果準備黑SQLServer的請自行路過，我雖然不認為SQLServer是一個好的產品，但是我希望通過它去帶我進入資料庫領域，我更希望通過一個產品理解資料庫理論，而不是深入研究一個產品。），下面列出10個可能幫你最小化運維複雜度和降低壓力的方法。

在過去的幾年裡面，很多公司都在削減IT部門。很多DBA不得不負責越來越多的SQLServer資料庫。更糟糕的是，他們之中很多並不是純DBA，有些實際上是非自願成為DBA而不是專業人員，有時候他們僅僅充當消防員的角色進行一個又一個的危機處理。這種情況是非常危險、困難並且難以持續的。因為沒有人喜歡無休止的壓力和干擾。

應對這種情況的其中一個方法是把SQLServer環境流程化，使其更容易理解和管理。基於我的（指作者）的顧問經歷，總結出10條關於SQL Server DBA用於控制環境及降低整體危機發生的可能性的方法。這個列表按重要性排序。

 

10． 製作清單（Take Inventory）：

你有多少次被要求還原那些你可能在此之前完全不知道它們存在的資料庫的資料？由於現今企業中資料庫的擴充套件非常常見，所以DBA團隊可能會忽略了對資料庫例項的跟蹤歸檔。這就導致了很多資料庫沒有備份、沒有打補丁、沒有合適的安全措施和錯過了一些在重要機器上實施過的管理任務。

所以，建立一個與時俱進的關於企業內部及你所管控的例項和資料庫清單非常重要。因為這是你能合理管理它們的唯一方法。這個清單也可用於幫助你建立工作職責。對已知的例項定義支援策略（support policies），並在新例項部署及交付DBA管理之前建立一個配置標準。

關於這個工作，業界有很多工具可以支援，比如簡單的工具有SQLPing3、SQLRecon，Quest Discovery Wizard的Planning Toolkit等。

譯者注：個人認為，無管理、不運營，無清單，不管理。你連自己管理的內容、管理的物件、管理的數量等等都不知道，你說你能管理、能管好？我該不相信呢？還是不相信呢？有一個up-to-date的清單你可以輕易回答管理層提出的很多問題，諸如：現在有多少個伺服器？有多少個資料庫？用的是什麼版本？資料庫大小是多少？有多少個表？最大的表有多少行（其實大表不能僅看行，還要看列及資料型別）等等。並且可以通過這些清單去做資源規劃、架構管控等任務。

 

9． 標準化配置（Standardize Configurations）：

如果負責的資料庫數量不斷地增長，你會發現不同的配置也會隨之不斷地增長。這種情況下，在例項之間的工作切換會變得非常困難及低效。因為可能對於不同的系統要使用不同的配置，即使一個完整的應用系統，可能也涉及好幾個伺服器，每個伺服器又承擔不同的任務，導致配置的不同，管理起來的難度相當“感人啊！”

針對這個問題，需要標準化你的環境，包括碟符、伺服器配置項、資料庫配置、資料庫維護、安全設定等等。SQL Server 2008 引入了基於策略的管理（Policy-Based Management，PBM ）功能用於協助策略的定義和實施。微軟SQL Server專家制作了一個名為企業策略管理框架（Enterprise Policy Management Framework , EPM）可以用於在SQL2005和SQL 2000上實現PBM。（SQL 2008 EPMhttps://msdn.microsoft.com/en-us/library/dd542632.aspx）。這個工具的大概截圖如下：

在過去，本人通常想到什麼就做什麼，很少靜下心來回顧哪些可以合併，哪些是不足或者多餘的，但是在最近，隨著系統/資料庫的增加，這種憑經驗做事的方法確實帶來很多隱患和加大工作成本，所以本人建議如果想少點麻煩，還是要根據規章制度來比較靠譜。

 

8． 理解I/O子系統（Understand the I/O Subsystem）：

有幾個關於I/O子系統的因素會影響SQLServer例項的正常、高效執行。你需要知道它們及其潛在影響：注：I/O子系統不僅僅指磁碟，還包括記憶體、網路甚至CPU的部分功能。

• I/O子系統的能力：讀寫能力及其吞吐量和磁碟空間。它們必須能夠應對負載峰值的要求和在不得不購買/新增更多資源之前能應對空間增長壓力。通過標識I/O瓶頸和移動資料/日誌檔案到其他I/O子系統從而實現一定程度的負載均衡。負載均衡被說了很多年，已經逐漸被誤導成僅僅指通過橫向擴充套件分攤負載，雖然並沒有嚴重錯誤，但是我們應該更多地把注意力集中在對“負載”的均衡而不是著眼於僅僅想辦法把使用者請求分攤到多個伺服器上這種做法上。難道磁碟讀寫負載的分攤就不能稱為負載均衡了嗎？
• I/O子系統的容災能力：通常指RAID級別和是否能實現映象寫入備份或是其他形式的映象/複製（指I/O子系統層面而不是SQL Server層面）。保護磁碟上的資料檔案和日誌檔案避免出現故障是DBA的首要任務。（譯者注：在過去，很多人對穩定性、安全性、擴充套件性、高效性等系統特性排序時，都選擇了安全性或者高效性，但是個人認為，一個不穩定的系統，給你賬號密碼有什麼用？一登陸就崩潰，你能等到什麼？所以我認為穩定性才是一切的前提）。但是這種選擇又必須權衡，RAID 10能提供比RAID 5更好的容錯能力，但是成本更高。關於這部分可以看一下白皮書：PhysicalDatabase Storage Design
• I/O子系統的合理配置：RAID條帶大小（RAID stripe size），NTFS分配單元/叢集大小和分割槽對齊，這部分可以看：http://www.sqlskills.com/BLOGS/PAUL/post/Are-your-disk-partition-offsets-RAID-stripe-sizes-and-NTFS-allocation-units-set-correctly.aspx

7． 建立自定義的維護計劃（Create a Customized Maintenance Plan）：

你不能僅僅把資料庫放到生產環境然後不管。（Youcan’t just put a database into production and walk away.）索引碎片會隨著時間越來越多，從而導致效能下降。統計資訊可能變得過時而導致次優/不合理的執行計劃產生從而影響效能。I/O子系統可能會崩潰，這導致備份必須無處不在。

對於這些問題，可以建立針對你資料庫自身的完整的維護計劃。一個定製的計劃遠好於一個沒有滿足你需求的通用計劃。這部分可以閱讀：Top Tips for Effective SQL Server Database Maintenance http://technet.microsoft.com/magazine/2008.08.database.aspx ，文章告訴你如何構建一個優秀的維護計劃。另外https://ola.hallengren.com/中的指令碼可以作為構建自定義維護計劃的切入點。

注：永遠不要盲目相信產品提供的功能，凡是能給你選擇用還是不用，開還是關的功能，都有其適用場景。SQL Server的維護計劃有不少的問題，Oracle的RAC也不能完全解決負載均衡的問題，不加思考地使用別人有意無意推薦的功能，並不見得安全有效。不過你應該感謝那些熱心幫助你的人。沒有誰天生就有義務幫你解決問題。

 

6． 確保系統的安全（Ensure the Security of Your System）：

花時間主動發現安全問題是極其重要的，這可以保證你不需要在發生之後才處理它們。在文章Common SQL Server Security Issues and Solutions 中列出了10個最常見的安全問題及其應對方案。同時，別忘了瞭解你係統的補丁情況以便你發現系統漏洞。

關於安全方面，建議看一下這兩本書《SyngressSecuring SQL.Server》、《Microsoft SQL Server 2012 SecurityCookbook》，雖然它是說SQL Server的，但是不管你用什麼RDBMS（關聯式資料庫管理系統，比如oracle、MySQL、DB2等等），學一下別人的思路總可以吧。關於第二本書，鄙人簡單翻譯了幾篇：http://blog.csdn.net/dba_huangzj/article/details/37906349

 

5． 處理好與開發團隊的關係（Get on Good Terms with Your Developers）：

在IT部門中的其中一個主要的鄙視鏈 是DBA團隊和開發團隊的關係。兩個團隊通常不能很好地理解對方的優先事項及其關注點——內容包括從開發進度到SQL Server設計的任何一部分。關於特性、效能問題、責任等的不同觀點成為了最常見的爭論所在。

積極與開發團隊溝通配合能使你的工作更加順暢。與開發團隊進行設計審查，在投入生產以前充分測試程式碼，儘量避免破壞性的錯誤，這些都可以進一步削弱團隊內部的關係。

注：我不希望每次都是DBA給開發人員“講課”、“培訓”，這會導致開發人員的可能的心理壓力，不排除他們覺得自己低人一等（希望是我多慮了），大家應該平等地溝通、交流，DBA說的往往是根據一些原理、規定、現象，但是不可能保證他們完全清楚一線人員的處境及實際專案的特點，所以我更希望大家交流一下關於專案的一切。

 

4． 制定一個完整的災難恢復策略（Develop a Comprehensive Disaster Recovery Strategy）：

不管你的基礎架構如何強悍，你都必須有一個應對偶發性災難的計劃。你不可能總能預知磁碟損壞、斷電、火災、突發性資料丟失和其他潛在問題。你需要對這些問題進行計劃性防禦及恢復。

與管理部門一起確定資料庫停機時間和資料丟失的SLA，制定計劃用於把資料從各種故障中恢復，確定你的資料庫及所有SQL 例項能符合企業的業務連續性計劃。對所有資料庫和例項制定故障恢復的優先順序。注：這段看上去其實有點扯淡，你去問業務部門試試，他們肯定只告訴你：0丟失、0停機 。但是他們不知道即使是世界上最大的IT企業甚至美國國防部都不可能做到0停機。不過有必要的時候還是告知一下，最起碼你得讓他們知道“成本”問題。

同時也需要使用一些技術來協助你知道問題何時發生，比如資料頁校驗（page checksums）、一致性檢查（consistency checks）、SQL 代理警報和系統操作管理器警報。這些災難恢復基礎架構配合備份、日誌傳送、複製和資料庫映象及其他技術可以用於更好地保護資料。關於這方面可以月度微軟白皮書：High Availability with SQL Server 2008 和 Proven SQL Server Architectures for High Availability andDisaster Recovery 。

 

3． 定期實施和測試備份（Take and Test Regular Backups）：

不管你的高可用和災難恢復策略如何完美，你都不要放棄對資料庫的常規備份。如果你的資料庫損壞或者發生嚴重錯誤，可以依賴的只有最新的資料庫備份，如果沒有任何備份，企業將因此蒙受致命打擊。除了進行常規備份，同時也要對備份檔案進行週期性還原測試以便保證備份檔案可用。注：沒有常規校驗的備份檔案應該列入不可信任的檔案，如果條件允許，應該把備份檔案移到一個有足夠空間的伺服器進行完整還原。另外在本人某家公司任職時，被要求對初級DBA進行培訓，當時第一課就是講備份，可惜他們根本不想聽，認為對備份認識已經足夠了，但是人家大公司的Oracle的DBA團隊通常都有幾個人專門做備份啊，只做備份這一件事啊親！人家工資還比我高啊！！

關於這部分可以閱讀：Understanding SQL Server Backups 和 SQL Server: Recovering From Disasters Using Backups.

 

2．監控和維護效能（Monitor and Maintain Performance）：

效能優化一直是DBA日常工作的重要組成部分，但是也有很多方式去流程化這部分的工作：

• 建立效能基線以便用於判斷是否效能發生了改變。
• 把系統拆分成可以度量的原子部分，並且確保它們不會收到外界影響。
• 使用“等待和佇列”快速定位效能問題。
• 使用系統基礎資訊、效能計數器、等待資訊去監控效能，也可以使用SQL 2008的效能資料收集功能和2005開始的效能儀表盤功能，通過它們可以得知效能狀態從何時開始下降。
• 建立一個維護計劃。
• 使用如資料庫引擎優化顧問（DatabaseEngine Tuning Advisor，DTA，注：本人不認為DTA是個可以常用的工具，因為本人見到太多濫用導致更多問題的例子，使用時請先了解其優缺點及限制情況）、關於索引的動態管理檢視（Dynamic Management Views，DMVs）去發現和實施索引策略。

 

1．  知道從哪裡找到資訊（Know Where to Find Information）：

這是一個永無止境的任務清單，知道何時放棄並尋求幫助至關重要。你必須承認自己的能力有限，並且接受你不可能知道關於SQL Server的一切。所以在你發現你已經無法處理問題時應該學會尋求幫助。

首先可以找到關於SQL Server資訊的地方是廣為人知的SQL Server聯機叢書（簡單來說就是使用手冊），可以使用它來查詢語法，但是如果你需要的是一些複雜問題的解決方案，更可靠的還是線上論壇和搜尋引擎。

另外一個方法是在SQL Server社群中@SQL專家。引起他們的關注。

注：原文還有不少關於這部分的內容，但是我覺得有點不適合國內玩家，最少大部分人都登入不了Twitter。反正記住別走極端就好了。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/29371470/viewspace-2143990/，如需轉載，請註明出處，否則將追究法律責任。