3. Microsoft SQL Server 数据库管理员的角色和任务Microsoft Windows 2000 平台
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 就更抢手了！
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 就更抢手了！
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
