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

擺脫這種境況的一個方法是花點功夫來簡化您的 SQL Server 環(huán)境，使之更易于理解和管理。我根據(jù)擔(dān)任 SQL Server 顧問的實際經(jīng)驗總結(jié)出了以下十種方式，可以幫助 SQL Server DBA 提高對環(huán)境的控制力，并減少發(fā)生危機的可能性。這些方式按大致的重要程度列出，越往后越重要。

10. 編制清單

有多少次當(dāng)您被要求還原受損的數(shù)據(jù)庫數(shù)據(jù)時，您甚至不知道這些數(shù)據(jù)的存在？SQL Server 數(shù)據(jù)庫很容易在公司內(nèi)泛濫。DBA 團隊可能不知道數(shù)據(jù)庫中哪些數(shù)據(jù)不在了，從而失去對 SQL Server 實例的控制。這樣一來，未進行備份、修補的數(shù)據(jù)庫可能無法采取恰當(dāng)?shù)谋Ｗo，并錯失其他很多必要的管理任務(wù)。

因此，當(dāng)務(wù)之急是掌握您可控的公司實例和數(shù)據(jù)庫***清單。這是有效管理它們、必要時進行合并，并正確劃定范圍和規(guī)劃項目及升級的唯一途徑。編制清單還可以幫助您在與公司內(nèi)各個團隊協(xié)商之后，通過公布您負責(zé)的已知實例列表來明確您的職責(zé)。您可以擬定已知實例的支持策略，并要求新實例嚴格遵守您的配置準(zhǔn)則，否則將不予支持。

有許多工具可以幫助您創(chuàng)建 SQL Server 清單，例如，像 SQLPing3 和 SQLRecon 這樣的簡單工具、Microsoft 評估和計劃工具包和 Quest Discovery 向?qū)У取?/p>

9. 標(biāo)準(zhǔn)化配置

如果您負責(zé)的數(shù)據(jù)庫和 SQL 實例數(shù)量在不斷增長，您會發(fā)現(xiàn)不同配置的數(shù)量也在以類似的方式增長。如果您不得不記住不同實例的配置細節(jié)，那么很難在面對不同實例時取得高效。

解決方法是盡可能標(biāo)準(zhǔn)化配置信息，如驅(qū)動器號、服務(wù)器配置選項、數(shù)據(jù)庫設(shè)置、數(shù)據(jù)庫維護、安全設(shè)置等等。SQL Server 2008 中引入了基于策略的管理功能，可幫助定義和實施策略。此外，Microsoft 的 SQL Server 技術(shù)專家 Lara Rubbelke 開發(fā)出了企業(yè)策略管理 (EPM) 框架，可輕松擴展到 SQL Server 2005 和 SQL Server 2000 實例上。您可以從 CodePlex 獲取該 EPM 框架。圖 1 顯示了一個 EPM 框架報告示例。

圖 1 企業(yè)策略管理框架報告

8. 了解 I/O 子系統(tǒng)

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

I/O 子系統(tǒng)的讀/寫吞吐量和磁盤空間容量。必須能滿足工作負荷峰值要求，并能在您不得不為增長的數(shù)據(jù)量購買更多容量之前提供足夠的空間。您可以確定 I/O 瓶頸并將數(shù)據(jù)和/或日志文件移至 I/O 子系統(tǒng)的其他部分，從而更均勻地平衡負載。

I/O 子系統(tǒng)的 RAID 級別冗余能力以及能否執(zhí)行諸如分割鏡像備份的操作和任何形式的鏡像/復(fù)制（在 I/O 子系統(tǒng)層面，而非 SQL Server 層面）。保護好數(shù)據(jù)和日志文件，避免因驅(qū)動器故障和其他潛在問題而遭受損失是很重要的。但這往往要進行折衷 - RAID-10 的冗余能力勝過 RAID-5，價格也更昂貴。有關(guān)詳細指南，請參見白皮書“物理數(shù)據(jù)庫存儲設(shè)計”。

I/O 子系統(tǒng)的 RAID 條帶大小、NTFS 分配單元/簇大小和分區(qū)對齊是否配置正確。有關(guān)詳細信息，請查看我的博客帖子“Are your disk partition offsets, RAID stripe sizes, and NTFS allocation units set correctly?（您的磁盤分區(qū)偏移量、RAID 條帶大小和 NTFS 分配單元設(shè)置是否正確？）”。

7. 創(chuàng)建自定義維護計劃

我在教授數(shù)據(jù)庫維護課程時，總是以“你不能只是把數(shù)據(jù)庫付諸生產(chǎn)，然后聽之任之”作為開頭語。索引會隨時間變得越來越零碎，從而導(dǎo)致性能降低。統(tǒng)計信息逐漸過時，從而導(dǎo)致不良查詢和惡化的性能。I/O 子系統(tǒng)可能遭到破壞，對備份的需求永無止境。

您可以為數(shù)據(jù)庫定制一個全面的維護計劃，來解決以上所有問題。自定義的計劃遠比不能充分滿足需求的通用計劃好得多。我曾于 2008 年 8 月在《TechNet 雜志》上發(fā)表了“高效維護 SQL Server 數(shù)據(jù)庫的關(guān)鍵技巧”一文，其中介紹了如何創(chuàng)建好的維護計劃。建立自己的維護計劃的***開始方式是使用 Ola Hallengren 編寫的免費腳本。我一直推薦客戶使用該腳本。

6. 確保系統(tǒng)安全性

花點時間主動發(fā)現(xiàn)安全問題是很有必要的，可以防止事件發(fā)生，而不用事后再做處理。我的另一篇《TechNet 雜志》文章，“常見的 SQL Server 安全性問題和解決方案”，列出了十個最常見的安全問題以及規(guī)避方法。此外，發(fā)現(xiàn)漏洞時別忘了及時修補系統(tǒng)。

5. 處理好與開發(fā)團隊的關(guān)系

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

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

4. 制定全面的災(zāi)難恢復(fù)策略

無論您的基礎(chǔ)結(jié)構(gòu)有多牢固，當(dāng)災(zāi)難降臨時您必須具備應(yīng)急計劃。您無法預(yù)知損壞、停電、火災(zāi)、意外數(shù)據(jù)丟失或其他諸多潛在問題，因此，您需要一個計劃來應(yīng)對這些問題并進行恢復(fù)。

您可以和管理層一起擬定數(shù)據(jù)庫的停機時間及數(shù)據(jù)丟失軟件許可協(xié)議，對如何從各種數(shù)據(jù)丟失類型中恢復(fù)做出規(guī)劃，并確定如何將數(shù)據(jù)庫和所有 SQL 實例納入公司的業(yè)務(wù)連續(xù)性計劃。弄清楚所有數(shù)據(jù)庫和實例的相對重要性，以便確定災(zāi)難恢復(fù)的優(yōu)先次序。

您還需要借助其他技術(shù)來幫助了解問題發(fā)生的時間，例如，頁面校驗和、一致性檢查、SQL 代理警報和 System Center Operations Manager 警報等。災(zāi)難恢復(fù)基礎(chǔ)結(jié)構(gòu)可通過備份、日志傳送、復(fù)制和數(shù)據(jù)庫鏡像來幫助您保護數(shù)據(jù)，并有可能通過數(shù)據(jù)庫鏡像或故障轉(zhuǎn)移群集將故障轉(zhuǎn)移到冗余系統(tǒng)上。以下兩個 Microsoft 白皮書可為您提供幫助：“High Availability with SQL Server 2008（SQL Server 2008 高可用性）”和“Proven SQL Server Architectures for High Availability and Disaster Recovery（具備高可用性和災(zāi)難恢復(fù)功能的經(jīng)檢驗的 SQL Server 體系結(jié)構(gòu)）”。

3. 定期備份并進行測試

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

您可以從我 2009 年為《TechNet 雜志》撰寫的兩篇文章中找到更多信息：“Understanding SQL Server Backups（了解 SQL Server 備份）”和“SQL Server:Recovering From Disasters Using Backups（SQL Server：使用備份進行災(zāi)難恢復(fù)）”。

2. 監(jiān)視和維護性能

性能調(diào)節(jié)占據(jù)了 DBA 的大部分時間，但有很多方法可以簡化這個過程：

建立性能基準(zhǔn)，以便了解性能是否真的發(fā)生了變化。

將系統(tǒng)分解為可在無外部因素干擾下隔離測量的基元。

使用等待-排隊方法快速查明性能問題。

采用系統(tǒng)基元、性能計數(shù)器監(jiān)視性能，并等待統(tǒng)計信息。這樣您會知道性能何時開始下降?？墒褂?SQL Server 2008 中的性能數(shù)據(jù)收集器功能以及 SQL Server 2005 的性能儀表板。

制定維護計劃。

借助工具認真規(guī)劃和執(zhí)行索引策略，如數(shù)據(jù)庫引擎優(yōu)化顧問、DTA、缺失索引動態(tài)管理視圖 (DMV) 和索引使用 DMV。

1. 懂得從何處尋找信息

要做的事情無窮無盡，懂得何時放手并尋求幫助才是上上之策。您應(yīng)當(dāng)了解自己的局限性，清楚自己不可能了解有關(guān) SQL Server 的一切。如果有人能幫助您完成任務(wù)或解決問題，那么您沒有必要自己苦苦掙扎并浪費寶貴的時間。

您的首要 SQL Server 信息源是 SQL Server 聯(lián)機叢書，您可以下載并安裝到本地，或在 MSDN 中聯(lián)機搜索?！禨QL Server 聯(lián)機叢書》很適合用來查詢語法，但如果你有更復(fù)雜的操作問題，或正嘗試解決某個問題，那么***的辦法是將問題發(fā)布到聯(lián)機論壇。MSDN 上有許多 SQL Server 論壇，還有一些熱門的社區(qū)站點，如 SQL Server Central。

還有一種尋求幫助的快速方式是借助 Twitter 的 SQL Server 社區(qū)。發(fā)布問題時加上 #sqlhelp 哈希標(biāo)簽，很多 SQL 專家（包括我）便可以看到您的問題。

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

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

原文地址

查看更多相關(guān)文章

【編輯推薦】

1. SQL Server 2000刪除實戰(zhàn)演習(xí)
2. SQL Server存儲過程的命名標(biāo)準(zhǔn)如何進行？
3. 卸載SQL Server 2005組件的正確順序
4. 對SQL Server字符串?dāng)?shù)據(jù)類型的具體描述
5. SQL Server數(shù)據(jù)類型的種類與應(yīng)用