SQL Sever DBA 的基本 / 選擇工作項目
DBA 的小技術
本章總結
Microsoft SQL Sever 資料庫管理員(DBA)並沒有一套制式化的任務模式，各企業機關的資料庫管理員的規模和管理技巧均不盡相同。有些公司的 DBA 從發展到維護均一手包辦，有些公司則讓不同的 DBA 各自負責系統操作的一小部份。兩種管理模式都各有優點，各公司可依需求自訂。
今日的資料庫系統管理階層是高科技職場的新貴，一個好的 DBA 在職場上更是搶手。若是您可以往這方面繼續進修，相信您在職場上將更有競爭力。
在這一章，您會學到一個 SQL Sever DBA初階和進階的工作內容，以及成為一個頂尖的 DBA 所要知道的技巧。雖然列舉出來的工作項目繁多，但有許多項目並不是每天例行的公事，有許多項目甚至是當遇到問題時才需要檢視的。不管處理哪一個項目，DBA 都需以穩當的態度及靈活的方式處理事件。這一章會教您如何從容的處理您的工作。
SQL Sever DBA 的基本 / 選擇工作項目
雖然每個 DBA 的工作內容會依各公司的要求而有所不同，但有些基本的工作項目是大部份 DBA 皆同的。如果這裏提到的項目和您的工作內容有所不同，您也不必太擔心，每個 DBA 總會有些性質上的差異。在這一章我們以介紹完整的 DBA 工作內容為主軸，提供新進行的 DBA 一個全面性的工作內容介紹，因此也許有些工作內容是您不甚熟悉的。我們把這些工作項目作了分類，不過它們分類的方法和工作內容的難易度或工作量是無關的。
安裝和設定
SQL Sever DBA 常常被要求支援新軟體的安裝及協助軟硬體的設定，有時只需列出安裝或設定軟硬體時所需要的設備，或被要求參與和安裝設定有關的計畫。不論是哪種情況，DBA 都必須確定所安裝或設定的系統和資料庫是可執行 SQL Sever 的最佳化設定。
軟體安裝
安裝 SQL Sever 的 DBA 除了必須負責安裝軟體之外，還得一併考慮 Microsoft Windows 2000 和其他軟體的安裝。安裝時必須注意每一個選項是否有安裝的必要性，以 Windows 2000 來說，很容易就會安裝一些原來不想安裝在系統上的元件，如 Internet Information Server (IIS)、Dynamic Host Configuration Protocol (DHCP)伺服器、訊息佇列以及加重系統負擔的一些檔案或印表機上的服務。
要避免安裝不必要的元件，在設定 Windows 2000 之前先列一張安裝清單是一個不錯的方法。清單的內容可列出哪些是確定要安裝的元件，您可重複使用這張清單來裝新的 Windows 2000，以確保安裝 Windows 2000 的一致性。
DBA 除了要正確的設定 Windows 2000 外，也必須正確的安裝 SQL Server 2000。因為很多選項若是您在一開始安裝 SQL Sever 時沒有事先規劃，可能就得重新安裝軟體才能變更設定了，如 SQL Server 二進位碼檔案和資料檔案的存放位置就是一例。
如果是第一次安裝 SQL Server 2000，可以不用馬上就把軟體安裝在正式運作的系統上，而考慮將軟體先安裝在測試系統上。這樣您就可以試試不同的選項，並熟悉系統運作。如之前所建議的，安裝 SQL Sever 時最好把安裝步驟也寫下來。
軟硬體設定
雖然 DBA 一般都不需要做設定硬體伺服器的工作，但也有例外的時候。當安裝時，若沒有自行實際設定軟硬體，就應該要非常清楚並且保證設定的內容有按您的要求一一做到。身為 SQL Server 的 DBA，為了要負責整個系統的有效性和穩定性，必須要用您的知識和經驗將 SQL Server 系統設定在最佳的性能和效果，以及最大容量和成長空間的狀況下。除此之外，您也需要具備可斷定磁碟機和控制器數目，還有提供任何 RAID 控制器詳細內容的能力。
安裝軟體時，為了要記得整個設定的過程和邏輯以利於節省將來要設定時所花費的時間和精力，最好將第一次安裝時所做的決定和其中邏輯思考的過程都紀錄下來。這些紀錄同樣也能作為日後修改程式和軟硬體升級的參考。當然，記錄的內容切記要包括使用了哪些 PCI buses 和 RAID 控制器是如何設定的細節等。因為有些設定參數必須要在重新啟動電腦時的診斷狀態下才能找到，所以如果此時您手中握有當初設定時的詳細內容，將有助於您省下大把的時間和體力。
切記：由於 DBA 的責任是要確保 SQL Server 資料庫的有效和穩定，因此整個系統的設定亦皆屬責任範圍內。千萬要確定 SQL Server 系統已完整地設定妥當。詳實紀錄設定時所做的決定，有助於別人的了解並證實您所做的選擇是有效的。
安全性
監視系統的安全性及隨時報告所發現的問題是 SQL Server DBA 的另一項責任。通常在自家公司或外面的公司都會有這方面的專業人員提供此相關業務。一個系統需要什麼種類或多少份量的安全系統，取決於您使用系統的權限範圍。假設一個沒有與網路相連接的系統僅供給幾位可信賴的員工使用，顯然地，這樣的系統所需的安全裝置不會比一個與網路有連接的系統所需要的安全裝置來得複雜。
系統的安全裝置是非常重要的，因為如果公司的系統遭到不肖份子的侵入而盜取或破壞資料，將會面臨更慘痛的代價。系統的安全裝置要從管理使用者開始，此部份將會在下一節討論。除了管理使用者之外，DBA 也需要設計並實施網路保全計劃，這方面的工作通常會指派給具有網路保全相關經驗的資深人員執行。所以假使您有這方面的經驗，就可以成為網路保全行政專員或是 DBA 專業人員。
網路保全
很多公司都有販售網路保全的解決方案，而負責網路保全的人員要負責採購、安裝及配置代理主機和 security gateway 等事宜。在 SQL Server 來說，主要的網路保全是在使用者的稽核和管理。
系統稽核
系統稽核包括監控 SQL Sever 錯誤記錄檔和 Windows 2000 事件記錄檔，以及使用 SQL Server Profiler 監控 SQL Server 本身的事件。SQL Sever 記錄檔和事件記錄檔記載 SQL Sever、Windows 2000 及與保全有關的重要資訊。必須定時監控這些資料以確保系統內部的安全。
SQL Sever 內部的事件可透過 SQL Server Profiler 來稽核，如記載登錄錯誤的記錄檔。您也可以將事件存檔，如 data definition language (DDL) statement 和插入、更新及刪除的功能。SQL Server Profiler 還可用來監控特定的事件、登入的時間、使用者名稱及相關活動。
操作
每日的例行工作可能會花掉 SQL Sever DBA 最多的時間。這些例行工作雖然繁瑣，但卻是一定要做的。如 DBA 要負責系統在運作時的問題，和運作時的備份及回復。
備份和回復
執行規則複製和週期性地測試備份是工作的一部分。如果系統出現了故障，在很多情況下，使用備份是回復資料庫的唯一途徑。但是如果沒有正確的執行備份，就不可能回復資料庫，那會導致資料的遺失和可能好多天的停機，甚至可能損失數百萬美元。因此，備份和回復過程是 DBA 的關鍵職責。DBA 必須定期和正確的執行這個任務。所以說雖然這項工作看似沒有挑戰性，但可確保當機時還可找回資料。
使用者管理
使用者管理是 DBA 另一項例行工作，包括管理 SQL Server 的登入和使用者權限。任何一個需要使用資料庫的員工都必須先透過 DBA 設定其權限才得以進入系統。通常，在開方權限時，DBA 需要取得人力資源部門的核准。千萬不可以完全開放一個人的權限，而應該依照該部門所需要的資料來開放相關的權限。
其他例行的維護工作
其他例行的維護工作包含監控資料庫可用空間、重新編列索引、檢查資料庫物件和監控系統的健全。因為系統內任何一項改變都有可能是由於系統發生問題所造成，所以監控系統的改變是非常切身的。如果您覺得每天執行的例行工作相當繁瑣而費時，您也可以使用自動監控系統來執行部分例行的檢查，但還是要定期親自地監控所有的例行工作。
服務等級
確保系統可提供特定等級的服務是非常重要的。有些服務等級會詳細說明於服務合約中，有些則沒有提供相關的服務合約。DBA 有責任確定這些沒有提供服務合約的系統已設定在最佳的工作狀態中，例如設定最大化的工作量，及經由效能調整設定最大的效能。
調整及監控
系統的監控需要靠平時的觀察累積經驗。如果突然遇到反應時間變長、所使用的 CPU 容量變大等狀況，可能都是系統出現問題的預兆。當您遇到不同的系統，監控的方式及解釋監控的結果也會隨之不同。因此必須根據所遇到的系統作判斷並解決問題。
您也必須定期監控系統的資源使用情形。如此，就可以在系統效能降低時即時加大系統。
一旦系統容量到達不敷使用的狀況，加大系統的過程就更加昂貴和費時。SQL Server 提供了一些監控系統的工具，如下所列示：
系統監控 系統監控是一項 Windows 2000 的功能，可從 開始 清單中取得。這項功能是為了監控 SQL Server 和 Windows 2000 的資源使用情形。
SQL Server Enterprise Manager 提供資源使用資訊及一些有限的效能資訊。
協力廠商的RDBMS監控器 提供資料庫關聯性管理系統（relational database management systems: RDBMSs）的監控和警訊功能的組合。
網路監控器 用於某些場合的網路監控；可以使用 Microsoft Systems Management Server（SMS）或其他的協力廠商工具來達成。
使用者調查 用來收集關於使用者對系統效能的感受的資訊。保持與使用者的聯繫、確定他們是否滿意是很重要的。DBA 和使用者之間應該有頻繁的交流。
監控磁碟空間使用情況的工具 這些包括 Microsoft Windows Explorer和其他諸如協力廠商的監控工具。有一些工具可同時為 Windows 2000 和 SQL Server 提供監控的能力。
在使用者數量增加以及工作負荷增加的時候，系統可能就要進行調整。
容量規劃
DBA 除了作系統的監控和調整外，還必須了解系統的工作量。在某些情況下，需要請教專家來訂定系統的大小、對系統進行容量規劃。然而在一般情況下，DBA 負責確定是否超出了系統容量，並負責確定何時效能降低了或何時資源不足了，以進行事前的容量規劃。
系統的最佳化
正如之前所述，保持系統的最佳化是 DBA 的責任。因為如果系統沒有保持在最佳化，其效能降低的情況會導致您的客戶付出非常大的代價來維修。所以盡可能讓系統保持在最佳化就是 DBA 的責任了。
計劃並安排系統的中斷時間
詳細的規劃系統中斷時間，可以減少系統不必要的突然中斷。只要事先規劃好中斷的時間並通知所有使用者作預先的準備和安排，就可以減少系統中斷所造成的不必要傷害。如果您的資料庫有支援網路系統，就必須作另外的安排。
規劃系統進行定期的中斷維修處理可以讓使用者隨時保持在系統中斷的準備狀況中。將中斷時間設定在下班的時候，會盡量不影響到使用者，例如每個月的第一個星期日。
失效回復
另一個減少系統中斷時間的方法便是隨時準備好回復系統的失效或當機。系統當機有很多種原因，有時是因為硬體失效。通常，使用者只需要換掉一些失效的成分再重新啟動電腦，就可以回復硬體失效所造成的不當當機問題。如果問題是出在磁碟機，RAID 的保護可以避免資料的流失。但如果是整個array失效，就需要用備份回復資料庫了。以上任何一種情形通常都需要花上數小時來修復。
重新啟動電腦或回復資料庫雖然可以解決因軟體所造成的電腦當機，然而經常性的當機卻是非常惱人的。
更嚴重的問題是因為地震、水災或颱風等天災所造成的資料庫損毀及電腦系統的失效。天災還會導致停電及斷訊等問題，所以即使資料中心在天災過後已完成修復，系統仍無法與網路相連。
設立一個預備用的資料中心可以解決這樣的問題，因為當原資料中心受到天災侵襲時，預備用的資料中心就可以馬上啟用。雖然預備用的資料中心沒有辦法回復到所有天災當時所發生的交易及資料，但是仍可避免公司營運停止。這樣的預備資料中心應該由 DBA 負責計畫及執行。
文件管理
檔案管理 DBA 有責任管理資料庫系統所有的檔案，包括硬體和軟體的設定、安裝過程、維護記錄、軟體升級記錄和應用程式的更改。在必要的情況下，這些記錄可用來幫助重建系統。
管理系統的檔案是枯燥乏味的工作，但也是必須的工作。
檔案可以使用紙張或電子格式保存，如何對應您的裝備以使用它，這取決於DBA。下列是您可以使用的方法：
可以用一個單獨的檔案來記錄所有的裝備。這個檔案包含了裝置中的每個系統。系統管理員、DBA和系統操作員都可以存取和修改這個檔案。
可以用一個單獨的檔案來記錄裝備中的每個系統。再次強調，和系統操作 相關的每個成員必須可以在這個檔案中建立日誌項目。
系統管理員、DBA 和系統操作員可以記錄不同的檔案。管理團體中的任何人都可以修改這些日誌，因此這些日誌必須可以讓每個相關的人員檢視。
在系統失效或資料遺失的事件中，擁有系統的完整歷史可以幫助查明原始錯誤發生的位置，也可以幫助您重新建構系統。歸根究底，追蹤錯誤的原因是為了要避免將來的錯誤。但是，這樣的過程必須使用完整的檔案才行。千萬不要刪除任何檔案；只能增加檔案。
下面的清單是一個導引，可用來幫助您組織您的檔案，使這些檔案對您是有用處的。檔案可以分為兩種主要的種類：設定和日誌。
設定檔案
在嚴重故障的事件中，設定檔案（configuration documentation）可以提供重建系統所需的所有資訊。這些資訊應該包括下列內容：
硬體設定 記錄您系統中的硬體、硬體的原始設定和所有增加的變更，例如增加磁碟或記憶體。
軟體元件 記錄了安裝到系統的每個軟體元件及設定程序。關於安裝了哪些子元件和使用了哪些選項的細節內容是十分重要的。
資料庫設定 應該包括資料庫的規劃和架構、所有資料檔案的名稱和位置、每個檔案所屬的檔案群組，以及這些群組是如何建立的。這些資訊提供您一個參考，可以辨別在磁碟陣列失效的事件中遺失了哪些資料檔案。
軟體調整 包括所有的系統和資料庫設定參數。在做出調整更改時，應該記錄新的設定。
系統日誌
系統日誌（System Log）在系統失效或效能降低時便顯現其重要性。您可以依照以下所提供的資訊了解系統日誌對失效情形所提供的回復幫助。
觀察 DBA 工作的一個重要部分就是注意系統的變更並預測問題。對於非正常行為的觀察是必須記錄的。即使記錄非常簡單，例如簡單到「系統看上去很遲緩」的程度，這樣的記錄同樣是後續系統失效事件的有效線索。
系統變更 DBA 應該記錄硬體、作業系統和資料庫系統上執行的所有變更。各種項目應該按照事件順序排列，並且是完整的，但是不應有任何不必要的細節。
系統失效 在任何磁碟或其他元件失效時，都應該在系統日誌中記錄這個事件。這些資訊在確定元件失效的原因時是很有用的。
備份/回存操作 沒有必要在每次系統備份時進行記錄。然而，回復資料的執行應該進行記錄以顯示使用者行為的模式、應用程式的故障點或資料庫的架構。
排定的維護 在執行排程的維護時，DBA 應該記錄對系統做了些什麼。這些資訊可以是調查那些發生在排定維護之後不久系統失效的出發點。
保持關鍵事件和設定資訊的記錄，您可以確定哪兒出現了問題，並瞭解如何使系統返回到它應該處於的狀態。
設計檔案
依照公司對資訊技術部門的組織與需求而定，DBA 有時也需要參與系統的設計。無論如何，熟悉系統的設計可使 DBA 對系統融會貫通。
操作維護計畫
因為有些公司要求 DBA 執行備份、回復及維護使用者帳戶的例行工作；有些公司則要求系統操作者執行這些工作，一般的操作程序檔案需要小心的保存以利日後 DBA 或系統操作者的參考。這些操作程序必須仔細地解釋每一個步驟讓新手可以很快的了解。不然，因為這些備份的工作多半是在下班後才執行，新手在不了解操作程序的情況下只好打擾 DBA。為了避免這樣的情形發生，所以程序最好是愈詳細、愈完整，愈能達到效果。
損壞回復計畫
DBA 的職責之一就是每當系統失效時，可以迅速地挽救它，所以損壞回復計畫是用來回復失效系統的指南。因為基本系統有可能會隨時失效，為了讓其他 DBA 或操作人員可以在您不在場的時候執行回復的作業，損壞回復計畫就是一項重大的資源。
在設計損壞回復計畫前，DBA 應該要先分析讓系統有效的需求和系統所會遭遇的風險。對於小規模的公司，其損壞回復計畫的結果可能是建議公司準備一個使用備用帶回復的系統，因為小規模的公司不需要要求系統永遠處於百分之百的最佳有效狀況，少許因損壞而造成的失效時間是可以被允許的。欲增加系統的有效時間以減少系統失效的困擾，可以用錯誤容忍度較高的系統，例如執行微軟叢集服務─Microsoft Cluster Services (MSCS)。有些公司會因為系統失效一天而損失上百萬，因此這些公司應該實行一個更有效和完整的損壞回復計畫。通常，這樣的回復系統會設立在一處離公司較遠的地點，它可以在原系統當機斷訊的時後獨立運作，所以當天然災害發生而影響原系統時，另一地點的系統就可以代替原系統。有關於這種損壞回復的計畫檔案需要小心地保留以便於公司任何技術人員的了解和使用。
設計和發展
除了較傳統的資料庫相關職責外，有些公司也會利用 DBA 來從事系統發展。因為 DBA 非常熟悉目前系統的需求及作業容量，所以可提供對新系統有用的設計內容。這些設計和發展的職責如下所述。
資料模式化和分析
資料模式化是設計過程中的一個重要部分。它涉及到資料庫的邏輯設計，包括指定資料的相互關聯性和引用的完整性限制。要使這困難的過程變得容易，您可以用圖形來顯示資料庫架構的結構，並看出個體元件是如何相互聯繫的。資料模型顯示了資料庫的邏輯檢視，然後可以抽象化地成為實體的資料庫設計。正確的進行資料庫的模式化－就是建立一個有效的邏輯和實體的資料庫設計方案－效能可以得到最大的增強。
資料庫設計
資料庫設計通常由資料庫設計者完成，但是經常需要參考 DBA 的意見。有時候 DBA 可能也扮演資料庫設計者的角色。DBA終日與資料庫為伍，因此對於資料庫他們會有獨特的看法，而這有助於將來資料庫的設計。
預存程序發展
有時，DBA 也會需要設計或發展預存程序。因為 DBA 已非常熟悉系統資料庫及其中的資料，請他們來執行這項任務是再適合不過了。設計預存程序的難易度則全憑應用程式或公司的需求了。
應用程式的發展
DBA 在某些公司裡也要參與公司資料庫使用方面等應用程式的發展。公司資料庫使用方面相關的應用程式，例如預存程序的應用程式，可藉由 DBA 對於公司資料庫有一定程度的了解與熟悉而助益其應用程式的發展。
資源分享
DBA 有時也會被要求成為開發者、設計者和使用者的顧問角色。這種諮詢包括下列任務：
幫助一般使用者有關特定問題的協助，或者開發訓練課程，甚至親自教授課程。在很多情況下，特別的 SQL 也用於 Decision Support System（DSS）的封包查詢。
幫助開發人員，提供關於過去系統使用的情況以及新的進展對使用者的好處等資訊。這可能包括通知使用者可用的新資料表和索引，以及所有可能有用的新特性。
幫助設計人員，提供不同的設計特性對使用者有何益處等資訊。有時設計人員開發的應用程式可能缺少一些使用者希望或需要的特性，而將這些資訊傳遞給他們可能有助於將來的設計。如果使用者對於使用某些功能有問題，此時他們更可能向您提出問題，因此您是設計人員很好的資訊提供者。
分析資料庫中的資料以及資料的存取情況。這些資訊可以用來幫助容量規劃和調整過程。這同樣可以提供資料庫架構改進的資訊。
其他 DBA 職責
還有很多其他 DBA 的職責如下所述︰
叢集管理
如果您將 MSCS 與 SQL Server 一併執行，您就必須做叢集維護及叢集行政的工作。在一般的情況下，叢集的工作會在系統中自動執行，但是當有硬體的加入和叢集的改變時，就需要手動執行這些行政工作了。叢集的觀念目前僅能用於處理伺服器的失效。將來，新版的 Microsoft Windows 和 SQL Server，會介紹較大型的叢集功能來處理更複雜的安裝和管理功能。在那之前，叢集管理的工作是非常簡單易懂的。
複製管理
如果您使用 SQL Server複製，可能需要隨著叢集的發展，執行定期的維護任務。這些維護任務涉及到更改叢集屬性和升級系統的軟體。其他的維護任務可能涉及到增加系統的記憶體或磁碟容量。任何對叢集的更改應該只作為系統管理員和 DBA 之間的協調工作。
服務台
除了以上所提到的責任外，DBA 還可以支援諮詢工作。雖然諮詢工作會分派專業的支援人員，但 DBA 有時也會被要求從旁協助，例如訓練支援專員使用新的應用程式和資料庫功能的工作。
給予採購意見
通常，DBA 也會參與硬體和軟體的評估工作。這樣的評估工作包括檢閱軟硬體的細節部分或設立並管理這樣的標準檢查程序。為方便工作，DBA 也需要時常取得軟體備份來測試系統並評估產品對某些使用群的效用。在不同要求下，有些DBA也需要針對軟硬體的細節部分做完整的檢閱和評估報告。
性能監控
DBA 應該按時監控系統並計劃其成長。為此，DBA 可以藉由其他專業人員的協助來評量系統的大小和引導性能計劃的訓練。然而，在正常情況下，DBA 需要負責判斷系統性能是否有伸展到可及的範圍，還有系統何時會漸趨退化和資源何時會用盡。藉此，DBA 才可以建議公司增加其他資源以使系統達到最佳的表現狀況。
如果不小心地規劃監控程序，系統很有可能會遭遇記憶體不足、磁碟機空間不足或電腦中央處理機負擔過重的情形。這樣的情形，往往會中斷所有的交易，所以仔細小心地監控系統就可以避免這樣的情形發生。
網頁行政
在較小規模的公司裡，DBA 有時也需要負責維護公司的網頁。在規模較大的公司則通常會有專門維護和發展公司網頁的員工。維護網頁的工作和 DBA 是依賴網頁存取資料庫而定。SQL server 和 Windows 2000 對網頁都提供許多理想的工具。
DBA 的小技術
如您在本章節所視，DBA 有很多不同的工作及職責。要如何使系統使用群對您公司的 DBA 和資料系統 (IS) 部門有良好的印象全憑您如何去表現並完成您的工作。這一節就是要提供給您如何在系統使用者前表現您自己和如何慎重地處理問題等的一些技巧。要如何實際使用以下所介紹的小技巧，就需要視情形及您的主觀意見而定。
與使用者打交道
依照各人不同的職責劃分，您或許不用時常直接與使用者接觸。但是，懂得如何與使用者溝通，對 DBA 而言也是一項幫助。以下的幾個方法，可以讓您與使用者的溝通更加順利。
客戶永遠是對的
具有靈敏的外交手腕。因為有時客戶未必能全盤地了解問題所在或是無法正確得描述問題，所以當客戶提供您錯誤的訊息時，千萬不要與客戶發生爭執，反而應該盡您所能從他們身上得到問題的關鍵，因為這些使用者的反應正是您取得問題關鍵的最重要線索。
聆聽
仔細聆聽使用者的心聲。因為使用者是第一優先會發覺系統開始失效的人，所以如果可以常常拜訪他們、認識每個人所掌握的工作範圍、並詢問有關系統的相關運作狀況，就不難發現系統何時開始出現問題。
遵循黃金紀律
正如您所知：「己所不欲，勿施於人。」就算是別人不對，也不要當眾糾正他或與他發生衝突。為了讓使用者有效地學習，寧可用較友善的態度來教育他。這樣才有助於您結交日後的盟友而避免怨恨或枝節產生。要成為一個讓別人尊敬的 DBA，首先請記得遵循這項黃金紀律。
系統調整
DBA 為了維持系統的有效性，經常需要對系統作一些小調整。本節提供您一些調整上的小技巧好讓您有效率的調整並維護系統的有效性。第一，便是在調整時，記得以調整一個項目為限。因為這樣才可以輕易辨識出哪一樣調整真正提昇或降低了系統的功能。同時，做好調整時的紀錄亦有利於系統調整。
方才的建議或許再緊急狀況發生時較不易遵循。因此在發生這樣的狀況時，您便可以使用接下來所要介紹的「散彈方式」：只要同時改善多項組成元件，您便有更多的機會一次增進系統的功能。只是用這樣的方法便不易找出問題的癥結點。況且這樣的方法有時會因為選擇的項目而不經意地將原本的功能取消，導致系統沒有達到增進的效果。
處理危機
DBA 有時會面臨一些危機，以下要介紹的便是一些幫助您渡過難關的小技巧︰
不要慌張
有些緊急狀況往往在調查清楚之後發現其實狀況並非如此；然而有些非緊急的問題卻會在處理不當的情形下轉而成為緊急狀況。所以用平靜的心態來解決問題才可以避免犯下昂貴的錯誤。如果有必要，也可以選擇離開問題的現場，休息一下再來思考問題。另外，在自己沒有把握可以妥善解決問題的情況下，也不要羞於尋求外在的協助。記得要慢慢來不要慌張，選擇最適當的方法來面對問題。
不要妄下結論
自行鑑定問題所在，不要人云亦云馬上下結論。查清楚事情的真相以免因為聽信誇張化或不實的消息而妄下結論 。
小心謹慎
很多錯誤往往都是在匆忙中發生的。由於匆忙所造成的錯誤常常會使人在原錯誤還沒有更正的情況又下犯下另一項錯誤，使得問題變得複雜、情形更糟。所以要注意自己的情緒，千萬不要太緊張或太匆忙。按部就班來，問題自然迎刃而解。切記您的第一個目標就是︰不要讓情況更糟。
多休息
不要在身體狀況不佳的情形下工作。如果 DBA 在精神狀況不佳的情況下工作，往往會犯下更大而且難以彌補的錯誤。時時保持在最佳狀況，DBA 就能夠集中精神並靈敏地發覺問題所在。
請求支援
如果問題已經大到無法收拾，就趕緊請求支援。有很多這方面的專家可以幫助您渡過難關。千萬不要以為請求其他人的支援會很沒有面子，其實，如果您找對了人，將會提高您自己的聲譽。
本章總結
本章節已經介紹您 SQL Server DBA 的工作範圍及責任。當然了，一個公司的大小及 DBA 的人數會影響每一位 DBA 的工作職責。
有些 DBA 會負責執行例行資料庫管理以外的工作，例如系統設計和應用發展。既然 DBA 的責任取決於公司的的需求及 DBA的能力，那麼愈有技巧有能力的 DBA 就更搶手了！
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/gzwl/archive/2004/10/03/123789.aspx
DBA 的小技術
本章總結
Microsoft SQL Sever 資料庫管理員(DBA)並沒有一套制式化的任務模式，各企業機關的資料庫管理員的規模和管理技巧均不盡相同。有些公司的 DBA 從發展到維護均一手包辦，有些公司則讓不同的 DBA 各自負責系統操作的一小部份。兩種管理模式都各有優點，各公司可依需求自訂。
今日的資料庫系統管理階層是高科技職場的新貴，一個好的 DBA 在職場上更是搶手。若是您可以往這方面繼續進修，相信您在職場上將更有競爭力。
在這一章，您會學到一個 SQL Sever DBA初階和進階的工作內容，以及成為一個頂尖的 DBA 所要知道的技巧。雖然列舉出來的工作項目繁多，但有許多項目並不是每天例行的公事，有許多項目甚至是當遇到問題時才需要檢視的。不管處理哪一個項目，DBA 都需以穩當的態度及靈活的方式處理事件。這一章會教您如何從容的處理您的工作。
SQL Sever DBA 的基本 / 選擇工作項目
雖然每個 DBA 的工作內容會依各公司的要求而有所不同，但有些基本的工作項目是大部份 DBA 皆同的。如果這裏提到的項目和您的工作內容有所不同，您也不必太擔心，每個 DBA 總會有些性質上的差異。在這一章我們以介紹完整的 DBA 工作內容為主軸，提供新進行的 DBA 一個全面性的工作內容介紹，因此也許有些工作內容是您不甚熟悉的。我們把這些工作項目作了分類，不過它們分類的方法和工作內容的難易度或工作量是無關的。
安裝和設定
SQL Sever DBA 常常被要求支援新軟體的安裝及協助軟硬體的設定，有時只需列出安裝或設定軟硬體時所需要的設備，或被要求參與和安裝設定有關的計畫。不論是哪種情況，DBA 都必須確定所安裝或設定的系統和資料庫是可執行 SQL Sever 的最佳化設定。
軟體安裝
安裝 SQL Sever 的 DBA 除了必須負責安裝軟體之外，還得一併考慮 Microsoft Windows 2000 和其他軟體的安裝。安裝時必須注意每一個選項是否有安裝的必要性，以 Windows 2000 來說，很容易就會安裝一些原來不想安裝在系統上的元件，如 Internet Information Server (IIS)、Dynamic Host Configuration Protocol (DHCP)伺服器、訊息佇列以及加重系統負擔的一些檔案或印表機上的服務。
要避免安裝不必要的元件，在設定 Windows 2000 之前先列一張安裝清單是一個不錯的方法。清單的內容可列出哪些是確定要安裝的元件，您可重複使用這張清單來裝新的 Windows 2000，以確保安裝 Windows 2000 的一致性。
DBA 除了要正確的設定 Windows 2000 外，也必須正確的安裝 SQL Server 2000。因為很多選項若是您在一開始安裝 SQL Sever 時沒有事先規劃，可能就得重新安裝軟體才能變更設定了，如 SQL Server 二進位碼檔案和資料檔案的存放位置就是一例。
如果是第一次安裝 SQL Server 2000，可以不用馬上就把軟體安裝在正式運作的系統上，而考慮將軟體先安裝在測試系統上。這樣您就可以試試不同的選項，並熟悉系統運作。如之前所建議的，安裝 SQL Sever 時最好把安裝步驟也寫下來。
軟硬體設定
雖然 DBA 一般都不需要做設定硬體伺服器的工作，但也有例外的時候。當安裝時，若沒有自行實際設定軟硬體，就應該要非常清楚並且保證設定的內容有按您的要求一一做到。身為 SQL Server 的 DBA，為了要負責整個系統的有效性和穩定性，必須要用您的知識和經驗將 SQL Server 系統設定在最佳的性能和效果，以及最大容量和成長空間的狀況下。除此之外，您也需要具備可斷定磁碟機和控制器數目，還有提供任何 RAID 控制器詳細內容的能力。
安裝軟體時，為了要記得整個設定的過程和邏輯以利於節省將來要設定時所花費的時間和精力，最好將第一次安裝時所做的決定和其中邏輯思考的過程都紀錄下來。這些紀錄同樣也能作為日後修改程式和軟硬體升級的參考。當然，記錄的內容切記要包括使用了哪些 PCI buses 和 RAID 控制器是如何設定的細節等。因為有些設定參數必須要在重新啟動電腦時的診斷狀態下才能找到，所以如果此時您手中握有當初設定時的詳細內容，將有助於您省下大把的時間和體力。
切記：由於 DBA 的責任是要確保 SQL Server 資料庫的有效和穩定，因此整個系統的設定亦皆屬責任範圍內。千萬要確定 SQL Server 系統已完整地設定妥當。詳實紀錄設定時所做的決定，有助於別人的了解並證實您所做的選擇是有效的。
安全性
監視系統的安全性及隨時報告所發現的問題是 SQL Server DBA 的另一項責任。通常在自家公司或外面的公司都會有這方面的專業人員提供此相關業務。一個系統需要什麼種類或多少份量的安全系統，取決於您使用系統的權限範圍。假設一個沒有與網路相連接的系統僅供給幾位可信賴的員工使用，顯然地，這樣的系統所需的安全裝置不會比一個與網路有連接的系統所需要的安全裝置來得複雜。
系統的安全裝置是非常重要的，因為如果公司的系統遭到不肖份子的侵入而盜取或破壞資料，將會面臨更慘痛的代價。系統的安全裝置要從管理使用者開始，此部份將會在下一節討論。除了管理使用者之外，DBA 也需要設計並實施網路保全計劃，這方面的工作通常會指派給具有網路保全相關經驗的資深人員執行。所以假使您有這方面的經驗，就可以成為網路保全行政專員或是 DBA 專業人員。
網路保全
很多公司都有販售網路保全的解決方案，而負責網路保全的人員要負責採購、安裝及配置代理主機和 security gateway 等事宜。在 SQL Server 來說，主要的網路保全是在使用者的稽核和管理。
系統稽核
系統稽核包括監控 SQL Sever 錯誤記錄檔和 Windows 2000 事件記錄檔，以及使用 SQL Server Profiler 監控 SQL Server 本身的事件。SQL Sever 記錄檔和事件記錄檔記載 SQL Sever、Windows 2000 及與保全有關的重要資訊。必須定時監控這些資料以確保系統內部的安全。
SQL Sever 內部的事件可透過 SQL Server Profiler 來稽核，如記載登錄錯誤的記錄檔。您也可以將事件存檔，如 data definition language (DDL) statement 和插入、更新及刪除的功能。SQL Server Profiler 還可用來監控特定的事件、登入的時間、使用者名稱及相關活動。
操作
每日的例行工作可能會花掉 SQL Sever DBA 最多的時間。這些例行工作雖然繁瑣，但卻是一定要做的。如 DBA 要負責系統在運作時的問題，和運作時的備份及回復。
備份和回復
執行規則複製和週期性地測試備份是工作的一部分。如果系統出現了故障，在很多情況下，使用備份是回復資料庫的唯一途徑。但是如果沒有正確的執行備份，就不可能回復資料庫，那會導致資料的遺失和可能好多天的停機，甚至可能損失數百萬美元。因此，備份和回復過程是 DBA 的關鍵職責。DBA 必須定期和正確的執行這個任務。所以說雖然這項工作看似沒有挑戰性，但可確保當機時還可找回資料。
使用者管理
使用者管理是 DBA 另一項例行工作，包括管理 SQL Server 的登入和使用者權限。任何一個需要使用資料庫的員工都必須先透過 DBA 設定其權限才得以進入系統。通常，在開方權限時，DBA 需要取得人力資源部門的核准。千萬不可以完全開放一個人的權限，而應該依照該部門所需要的資料來開放相關的權限。
其他例行的維護工作
其他例行的維護工作包含監控資料庫可用空間、重新編列索引、檢查資料庫物件和監控系統的健全。因為系統內任何一項改變都有可能是由於系統發生問題所造成，所以監控系統的改變是非常切身的。如果您覺得每天執行的例行工作相當繁瑣而費時，您也可以使用自動監控系統來執行部分例行的檢查，但還是要定期親自地監控所有的例行工作。
服務等級
確保系統可提供特定等級的服務是非常重要的。有些服務等級會詳細說明於服務合約中，有些則沒有提供相關的服務合約。DBA 有責任確定這些沒有提供服務合約的系統已設定在最佳的工作狀態中，例如設定最大化的工作量，及經由效能調整設定最大的效能。
調整及監控
系統的監控需要靠平時的觀察累積經驗。如果突然遇到反應時間變長、所使用的 CPU 容量變大等狀況，可能都是系統出現問題的預兆。當您遇到不同的系統，監控的方式及解釋監控的結果也會隨之不同。因此必須根據所遇到的系統作判斷並解決問題。
您也必須定期監控系統的資源使用情形。如此，就可以在系統效能降低時即時加大系統。
一旦系統容量到達不敷使用的狀況，加大系統的過程就更加昂貴和費時。SQL Server 提供了一些監控系統的工具，如下所列示：
系統監控 系統監控是一項 Windows 2000 的功能，可從 開始 清單中取得。這項功能是為了監控 SQL Server 和 Windows 2000 的資源使用情形。
SQL Server Enterprise Manager 提供資源使用資訊及一些有限的效能資訊。
協力廠商的RDBMS監控器 提供資料庫關聯性管理系統（relational database management systems: RDBMSs）的監控和警訊功能的組合。
網路監控器 用於某些場合的網路監控；可以使用 Microsoft Systems Management Server（SMS）或其他的協力廠商工具來達成。
使用者調查 用來收集關於使用者對系統效能的感受的資訊。保持與使用者的聯繫、確定他們是否滿意是很重要的。DBA 和使用者之間應該有頻繁的交流。
監控磁碟空間使用情況的工具 這些包括 Microsoft Windows Explorer和其他諸如協力廠商的監控工具。有一些工具可同時為 Windows 2000 和 SQL Server 提供監控的能力。
在使用者數量增加以及工作負荷增加的時候，系統可能就要進行調整。
容量規劃
DBA 除了作系統的監控和調整外，還必須了解系統的工作量。在某些情況下，需要請教專家來訂定系統的大小、對系統進行容量規劃。然而在一般情況下，DBA 負責確定是否超出了系統容量，並負責確定何時效能降低了或何時資源不足了，以進行事前的容量規劃。
系統的最佳化
正如之前所述，保持系統的最佳化是 DBA 的責任。因為如果系統沒有保持在最佳化，其效能降低的情況會導致您的客戶付出非常大的代價來維修。所以盡可能讓系統保持在最佳化就是 DBA 的責任了。
計劃並安排系統的中斷時間
詳細的規劃系統中斷時間，可以減少系統不必要的突然中斷。只要事先規劃好中斷的時間並通知所有使用者作預先的準備和安排，就可以減少系統中斷所造成的不必要傷害。如果您的資料庫有支援網路系統，就必須作另外的安排。
規劃系統進行定期的中斷維修處理可以讓使用者隨時保持在系統中斷的準備狀況中。將中斷時間設定在下班的時候，會盡量不影響到使用者，例如每個月的第一個星期日。
失效回復
另一個減少系統中斷時間的方法便是隨時準備好回復系統的失效或當機。系統當機有很多種原因，有時是因為硬體失效。通常，使用者只需要換掉一些失效的成分再重新啟動電腦，就可以回復硬體失效所造成的不當當機問題。如果問題是出在磁碟機，RAID 的保護可以避免資料的流失。但如果是整個array失效，就需要用備份回復資料庫了。以上任何一種情形通常都需要花上數小時來修復。
重新啟動電腦或回復資料庫雖然可以解決因軟體所造成的電腦當機，然而經常性的當機卻是非常惱人的。
更嚴重的問題是因為地震、水災或颱風等天災所造成的資料庫損毀及電腦系統的失效。天災還會導致停電及斷訊等問題，所以即使資料中心在天災過後已完成修復，系統仍無法與網路相連。
設立一個預備用的資料中心可以解決這樣的問題，因為當原資料中心受到天災侵襲時，預備用的資料中心就可以馬上啟用。雖然預備用的資料中心沒有辦法回復到所有天災當時所發生的交易及資料，但是仍可避免公司營運停止。這樣的預備資料中心應該由 DBA 負責計畫及執行。
文件管理
檔案管理 DBA 有責任管理資料庫系統所有的檔案，包括硬體和軟體的設定、安裝過程、維護記錄、軟體升級記錄和應用程式的更改。在必要的情況下，這些記錄可用來幫助重建系統。
管理系統的檔案是枯燥乏味的工作，但也是必須的工作。
檔案可以使用紙張或電子格式保存，如何對應您的裝備以使用它，這取決於DBA。下列是您可以使用的方法：
可以用一個單獨的檔案來記錄所有的裝備。這個檔案包含了裝置中的每個系統。系統管理員、DBA和系統操作員都可以存取和修改這個檔案。
可以用一個單獨的檔案來記錄裝備中的每個系統。再次強調，和系統操作 相關的每個成員必須可以在這個檔案中建立日誌項目。
系統管理員、DBA 和系統操作員可以記錄不同的檔案。管理團體中的任何人都可以修改這些日誌，因此這些日誌必須可以讓每個相關的人員檢視。
在系統失效或資料遺失的事件中，擁有系統的完整歷史可以幫助查明原始錯誤發生的位置，也可以幫助您重新建構系統。歸根究底，追蹤錯誤的原因是為了要避免將來的錯誤。但是，這樣的過程必須使用完整的檔案才行。千萬不要刪除任何檔案；只能增加檔案。
下面的清單是一個導引，可用來幫助您組織您的檔案，使這些檔案對您是有用處的。檔案可以分為兩種主要的種類：設定和日誌。
設定檔案
在嚴重故障的事件中，設定檔案（configuration documentation）可以提供重建系統所需的所有資訊。這些資訊應該包括下列內容：
硬體設定 記錄您系統中的硬體、硬體的原始設定和所有增加的變更，例如增加磁碟或記憶體。
軟體元件 記錄了安裝到系統的每個軟體元件及設定程序。關於安裝了哪些子元件和使用了哪些選項的細節內容是十分重要的。
資料庫設定 應該包括資料庫的規劃和架構、所有資料檔案的名稱和位置、每個檔案所屬的檔案群組，以及這些群組是如何建立的。這些資訊提供您一個參考，可以辨別在磁碟陣列失效的事件中遺失了哪些資料檔案。
軟體調整 包括所有的系統和資料庫設定參數。在做出調整更改時，應該記錄新的設定。
系統日誌
系統日誌（System Log）在系統失效或效能降低時便顯現其重要性。您可以依照以下所提供的資訊了解系統日誌對失效情形所提供的回復幫助。
觀察 DBA 工作的一個重要部分就是注意系統的變更並預測問題。對於非正常行為的觀察是必須記錄的。即使記錄非常簡單，例如簡單到「系統看上去很遲緩」的程度，這樣的記錄同樣是後續系統失效事件的有效線索。
系統變更 DBA 應該記錄硬體、作業系統和資料庫系統上執行的所有變更。各種項目應該按照事件順序排列，並且是完整的，但是不應有任何不必要的細節。
系統失效 在任何磁碟或其他元件失效時，都應該在系統日誌中記錄這個事件。這些資訊在確定元件失效的原因時是很有用的。
備份/回存操作 沒有必要在每次系統備份時進行記錄。然而，回復資料的執行應該進行記錄以顯示使用者行為的模式、應用程式的故障點或資料庫的架構。
排定的維護 在執行排程的維護時，DBA 應該記錄對系統做了些什麼。這些資訊可以是調查那些發生在排定維護之後不久系統失效的出發點。
保持關鍵事件和設定資訊的記錄，您可以確定哪兒出現了問題，並瞭解如何使系統返回到它應該處於的狀態。
設計檔案
依照公司對資訊技術部門的組織與需求而定，DBA 有時也需要參與系統的設計。無論如何，熟悉系統的設計可使 DBA 對系統融會貫通。
操作維護計畫
因為有些公司要求 DBA 執行備份、回復及維護使用者帳戶的例行工作；有些公司則要求系統操作者執行這些工作，一般的操作程序檔案需要小心的保存以利日後 DBA 或系統操作者的參考。這些操作程序必須仔細地解釋每一個步驟讓新手可以很快的了解。不然，因為這些備份的工作多半是在下班後才執行，新手在不了解操作程序的情況下只好打擾 DBA。為了避免這樣的情形發生，所以程序最好是愈詳細、愈完整，愈能達到效果。
損壞回復計畫
DBA 的職責之一就是每當系統失效時，可以迅速地挽救它，所以損壞回復計畫是用來回復失效系統的指南。因為基本系統有可能會隨時失效，為了讓其他 DBA 或操作人員可以在您不在場的時候執行回復的作業，損壞回復計畫就是一項重大的資源。
在設計損壞回復計畫前，DBA 應該要先分析讓系統有效的需求和系統所會遭遇的風險。對於小規模的公司，其損壞回復計畫的結果可能是建議公司準備一個使用備用帶回復的系統，因為小規模的公司不需要要求系統永遠處於百分之百的最佳有效狀況，少許因損壞而造成的失效時間是可以被允許的。欲增加系統的有效時間以減少系統失效的困擾，可以用錯誤容忍度較高的系統，例如執行微軟叢集服務─Microsoft Cluster Services (MSCS)。有些公司會因為系統失效一天而損失上百萬，因此這些公司應該實行一個更有效和完整的損壞回復計畫。通常，這樣的回復系統會設立在一處離公司較遠的地點，它可以在原系統當機斷訊的時後獨立運作，所以當天然災害發生而影響原系統時，另一地點的系統就可以代替原系統。有關於這種損壞回復的計畫檔案需要小心地保留以便於公司任何技術人員的了解和使用。
設計和發展
除了較傳統的資料庫相關職責外，有些公司也會利用 DBA 來從事系統發展。因為 DBA 非常熟悉目前系統的需求及作業容量，所以可提供對新系統有用的設計內容。這些設計和發展的職責如下所述。
資料模式化和分析
資料模式化是設計過程中的一個重要部分。它涉及到資料庫的邏輯設計，包括指定資料的相互關聯性和引用的完整性限制。要使這困難的過程變得容易，您可以用圖形來顯示資料庫架構的結構，並看出個體元件是如何相互聯繫的。資料模型顯示了資料庫的邏輯檢視，然後可以抽象化地成為實體的資料庫設計。正確的進行資料庫的模式化－就是建立一個有效的邏輯和實體的資料庫設計方案－效能可以得到最大的增強。
資料庫設計
資料庫設計通常由資料庫設計者完成，但是經常需要參考 DBA 的意見。有時候 DBA 可能也扮演資料庫設計者的角色。DBA終日與資料庫為伍，因此對於資料庫他們會有獨特的看法，而這有助於將來資料庫的設計。
預存程序發展
有時，DBA 也會需要設計或發展預存程序。因為 DBA 已非常熟悉系統資料庫及其中的資料，請他們來執行這項任務是再適合不過了。設計預存程序的難易度則全憑應用程式或公司的需求了。
應用程式的發展
DBA 在某些公司裡也要參與公司資料庫使用方面等應用程式的發展。公司資料庫使用方面相關的應用程式，例如預存程序的應用程式，可藉由 DBA 對於公司資料庫有一定程度的了解與熟悉而助益其應用程式的發展。
資源分享
DBA 有時也會被要求成為開發者、設計者和使用者的顧問角色。這種諮詢包括下列任務：
幫助一般使用者有關特定問題的協助，或者開發訓練課程，甚至親自教授課程。在很多情況下，特別的 SQL 也用於 Decision Support System（DSS）的封包查詢。
幫助開發人員，提供關於過去系統使用的情況以及新的進展對使用者的好處等資訊。這可能包括通知使用者可用的新資料表和索引，以及所有可能有用的新特性。
幫助設計人員，提供不同的設計特性對使用者有何益處等資訊。有時設計人員開發的應用程式可能缺少一些使用者希望或需要的特性，而將這些資訊傳遞給他們可能有助於將來的設計。如果使用者對於使用某些功能有問題，此時他們更可能向您提出問題，因此您是設計人員很好的資訊提供者。
分析資料庫中的資料以及資料的存取情況。這些資訊可以用來幫助容量規劃和調整過程。這同樣可以提供資料庫架構改進的資訊。
其他 DBA 職責
還有很多其他 DBA 的職責如下所述︰
叢集管理
如果您將 MSCS 與 SQL Server 一併執行，您就必須做叢集維護及叢集行政的工作。在一般的情況下，叢集的工作會在系統中自動執行，但是當有硬體的加入和叢集的改變時，就需要手動執行這些行政工作了。叢集的觀念目前僅能用於處理伺服器的失效。將來，新版的 Microsoft Windows 和 SQL Server，會介紹較大型的叢集功能來處理更複雜的安裝和管理功能。在那之前，叢集管理的工作是非常簡單易懂的。
複製管理
如果您使用 SQL Server複製，可能需要隨著叢集的發展，執行定期的維護任務。這些維護任務涉及到更改叢集屬性和升級系統的軟體。其他的維護任務可能涉及到增加系統的記憶體或磁碟容量。任何對叢集的更改應該只作為系統管理員和 DBA 之間的協調工作。
服務台
除了以上所提到的責任外，DBA 還可以支援諮詢工作。雖然諮詢工作會分派專業的支援人員，但 DBA 有時也會被要求從旁協助，例如訓練支援專員使用新的應用程式和資料庫功能的工作。
給予採購意見
通常，DBA 也會參與硬體和軟體的評估工作。這樣的評估工作包括檢閱軟硬體的細節部分或設立並管理這樣的標準檢查程序。為方便工作，DBA 也需要時常取得軟體備份來測試系統並評估產品對某些使用群的效用。在不同要求下，有些DBA也需要針對軟硬體的細節部分做完整的檢閱和評估報告。
性能監控
DBA 應該按時監控系統並計劃其成長。為此，DBA 可以藉由其他專業人員的協助來評量系統的大小和引導性能計劃的訓練。然而，在正常情況下，DBA 需要負責判斷系統性能是否有伸展到可及的範圍，還有系統何時會漸趨退化和資源何時會用盡。藉此，DBA 才可以建議公司增加其他資源以使系統達到最佳的表現狀況。
如果不小心地規劃監控程序，系統很有可能會遭遇記憶體不足、磁碟機空間不足或電腦中央處理機負擔過重的情形。這樣的情形，往往會中斷所有的交易，所以仔細小心地監控系統就可以避免這樣的情形發生。
網頁行政
在較小規模的公司裡，DBA 有時也需要負責維護公司的網頁。在規模較大的公司則通常會有專門維護和發展公司網頁的員工。維護網頁的工作和 DBA 是依賴網頁存取資料庫而定。SQL server 和 Windows 2000 對網頁都提供許多理想的工具。
DBA 的小技術
如您在本章節所視，DBA 有很多不同的工作及職責。要如何使系統使用群對您公司的 DBA 和資料系統 (IS) 部門有良好的印象全憑您如何去表現並完成您的工作。這一節就是要提供給您如何在系統使用者前表現您自己和如何慎重地處理問題等的一些技巧。要如何實際使用以下所介紹的小技巧，就需要視情形及您的主觀意見而定。
與使用者打交道
依照各人不同的職責劃分，您或許不用時常直接與使用者接觸。但是，懂得如何與使用者溝通，對 DBA 而言也是一項幫助。以下的幾個方法，可以讓您與使用者的溝通更加順利。
客戶永遠是對的
具有靈敏的外交手腕。因為有時客戶未必能全盤地了解問題所在或是無法正確得描述問題，所以當客戶提供您錯誤的訊息時，千萬不要與客戶發生爭執，反而應該盡您所能從他們身上得到問題的關鍵，因為這些使用者的反應正是您取得問題關鍵的最重要線索。
聆聽
仔細聆聽使用者的心聲。因為使用者是第一優先會發覺系統開始失效的人，所以如果可以常常拜訪他們、認識每個人所掌握的工作範圍、並詢問有關系統的相關運作狀況，就不難發現系統何時開始出現問題。
遵循黃金紀律
正如您所知：「己所不欲，勿施於人。」就算是別人不對，也不要當眾糾正他或與他發生衝突。為了讓使用者有效地學習，寧可用較友善的態度來教育他。這樣才有助於您結交日後的盟友而避免怨恨或枝節產生。要成為一個讓別人尊敬的 DBA，首先請記得遵循這項黃金紀律。
系統調整
DBA 為了維持系統的有效性，經常需要對系統作一些小調整。本節提供您一些調整上的小技巧好讓您有效率的調整並維護系統的有效性。第一，便是在調整時，記得以調整一個項目為限。因為這樣才可以輕易辨識出哪一樣調整真正提昇或降低了系統的功能。同時，做好調整時的紀錄亦有利於系統調整。
方才的建議或許再緊急狀況發生時較不易遵循。因此在發生這樣的狀況時，您便可以使用接下來所要介紹的「散彈方式」：只要同時改善多項組成元件，您便有更多的機會一次增進系統的功能。只是用這樣的方法便不易找出問題的癥結點。況且這樣的方法有時會因為選擇的項目而不經意地將原本的功能取消，導致系統沒有達到增進的效果。
處理危機
DBA 有時會面臨一些危機，以下要介紹的便是一些幫助您渡過難關的小技巧︰
不要慌張
有些緊急狀況往往在調查清楚之後發現其實狀況並非如此；然而有些非緊急的問題卻會在處理不當的情形下轉而成為緊急狀況。所以用平靜的心態來解決問題才可以避免犯下昂貴的錯誤。如果有必要，也可以選擇離開問題的現場，休息一下再來思考問題。另外，在自己沒有把握可以妥善解決問題的情況下，也不要羞於尋求外在的協助。記得要慢慢來不要慌張，選擇最適當的方法來面對問題。
不要妄下結論
自行鑑定問題所在，不要人云亦云馬上下結論。查清楚事情的真相以免因為聽信誇張化或不實的消息而妄下結論 。
小心謹慎
很多錯誤往往都是在匆忙中發生的。由於匆忙所造成的錯誤常常會使人在原錯誤還沒有更正的情況又下犯下另一項錯誤，使得問題變得複雜、情形更糟。所以要注意自己的情緒，千萬不要太緊張或太匆忙。按部就班來，問題自然迎刃而解。切記您的第一個目標就是︰不要讓情況更糟。
多休息
不要在身體狀況不佳的情形下工作。如果 DBA 在精神狀況不佳的情況下工作，往往會犯下更大而且難以彌補的錯誤。時時保持在最佳狀況，DBA 就能夠集中精神並靈敏地發覺問題所在。
請求支援
如果問題已經大到無法收拾，就趕緊請求支援。有很多這方面的專家可以幫助您渡過難關。千萬不要以為請求其他人的支援會很沒有面子，其實，如果您找對了人，將會提高您自己的聲譽。
本章總結
本章節已經介紹您 SQL Server DBA 的工作範圍及責任。當然了，一個公司的大小及 DBA 的人數會影響每一位 DBA 的工作職責。
有些 DBA 會負責執行例行資料庫管理以外的工作，例如系統設計和應用發展。既然 DBA 的責任取決於公司的的需求及 DBA的能力，那麼愈有技巧有能力的 DBA 就更搶手了！
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/gzwl/archive/2004/10/03/123789.aspx
全站熱搜
留言列表
網路相關技術 (3)
