本节书摘来自华章社区《DBA修炼之道：数据库管理员的第一本书》一书中的第1章，第1.6节DBA的任务，作者（美）Craig S. Mullins，更多章节内容可以访问云栖社区“华章社区”公众号查看
1.6 DBA的任务
DBA要能胜任多种任务以保证企业的数据和数据库是有用的、可用的、有效的、正确的。任务包括：设计、性能监控及调节、保证有效性、授权的安全性、备份与恢复、保证数据的完整性，还有和公司数据有关的一切。下面逐一研究。
1.6.1 数据库设计
人们认为DBA的首要任务就是建立设计完美的数据库。要想设计并建立合理的关系数据库，DBA就要懂得并遵循合理的关系设计原则。他们必须要懂得相关理论及用于建立数据库的RDBMS的具体实施细节。设计数据库要充分理解概念的和逻辑的数据模型知识。具备建立及解释实体关系图的能力对于设计关系数据库是必不可少的。
此外，DBA要能够把逻辑数据模型转换成物理数据库。DBA要保证设计和实施的数据库对应用程序及使用它的客户端是有用的。
DBA要能够把逻辑数据模型转换成物理数据库。
数据库设计确实是DBA要拥有的一项重要技能，而DBA的工作常与数据库设计不太相干。尽管设计最优的数据库很重要，但这只占据DBA工作相当小的一部分。相比最初的设计和搭建数据库，DBA在管理和调整数据库上花费的时间有可能更多。
尽管如此，你绝不能认为数据库设计不重要。一个糟糕的关系设计能导致糟糕的性能，一个不能满足企业需求的数据库，在某种意义上就是错误的数据库。
1.6.2 性能监控和调优
与DBA密切相关的第二种任务是性能监控和调优。但什么是数据库性能？暂且用我们熟悉的供需概念来考虑一下吧，用户对于数据库的需求信息，DBMS对这些需求所提供的信息。DBMS提供信息需求的速度就可以叫做数据库性能。但不会那么简单，有5种因素可以影响数据库性能：工作负载、吞吐量、资源、优化和竞争。
对DBMS请求的工作负载（workload）定义了需求。这结合了在线交易、批量作业、随机查询、数据仓库、分析查询，和在任意给定时间内直接通过系统的指令。工作负载可以每天、每小时、每分钟甚至每秒钟都大幅波动。有时候工作负载是可以预估的（比如，月底大量的结算过程，或下午七点半大部分用户下班后对数据库访问减少），但其他时间不可预估。整体工作负载对数据库性能有着重大的影响。
吞吐量定义了计算机硬件和软件的整体能力。这整合了I/O的速度、CPU的速度、机器的并行能力、操作系统及系统软件的效率。由系统支配的硬件和软件工具称为“系统资源”。例如，数据库内核、磁盘空间、高速缓存控制器和微代码。
数据库性能的第四个定义元素是优化。所有类型的系统都可以优化，但在这些优化中关系查询都是独特的，主要在DBMS内部完成。然而还有许多其他因素有待优化（SQL表述、数据库参数、有效的程序设计等），从而使数据库优化程序能够创建最有效的访问路径。
当对某一特殊资源的需求（工作负载）很高时，竞争就产生了。竞争产生的条件是：两个或多个工作负载元件试图以一种冲突的方式（例如，对同一数据段进行双重更新）使用单个资源。随着竞争的增加，吞吐量随之降低。
因此，数据库性能可以定义为资源利用的优化以增加吞吐量并减少竞争，从而最大可能地处理工作负载。
数据库性能可以定义为资源利用的优化以增加吞吐量并减少竞争，从而最大可能地处理工作负载。
每当使用数据库的应用程序遇到问题时，DBA常常会首先被叫过来解决问题。当然，DBA不能凭空管理数据库性能。应用程序会定期与其他应用程序、系统和IT基础设施组件进行通信。一种有效的性能监控调整策略不止需要DBMS专项技术，还需要数据库管理以外的知识。许多性能管理任务需要DBA和其他技术专家共同完成，换句话说，处理性能问题真的是种企业范围的努力。
DBA要在监控系统、数据库和应用程序性能中保持警惕，这通过自动化软件和脚本可以尽可能地实现。轮询系统表并构建基于临界值的警报可以主动识别这类问题。当性能指标不在期望范围内时，设置的警报可以发送电子邮件给DBA。
许多任务和能力的实现都要求DBA要保证数据库的有效访问。这些能力包括：建立恰当的索引，指定足够大的缓冲区和高速缓存，使数据库实现和IT基础设施相符，对数据库和应用程序的持续监控，数据库重构，以及适应业务的改变（更多的用户、更多的数据、附加的过程、改变需求和规则）。
1.6.3 保证可用性
数据和数据库的可用性常与性能密切相关，但实际上是分开考虑的。当然，如果DBMS处于脱机状态，性能表现将很可怕，因为没有数据能够访问。但保证数据库的可用性是个多方面的过程。
保证数据库的可用性是个多方面的过程。
可用性的第一要素是要保持DBMS持续运行。警惕监控与自动警报可以用来报告DBMS中断并要求补救措施。
个人数据库也必须维护，使得其中的数据可供应用程序和客户端调用。这样不仅需要DBA设计数据库，使得能以最小的中断去维护它，还要帮助设计应用程序，在需要并发访问时把冲突降到最低。
可用性的另外一个要素是要降低执行管理任务的停机时间。DBA执行需要数据库脱机的管理任务越快，数据可用性就越强。越来越多的DBMS供应商和独立软件开发商（ISV）提供不间断的实用程序，在数据库上执行它们，而应用程序通过它们对数据库进行读写。但这些通常需要更多的技巧和前期规划才能实现。
DBA必须了解所有这些方面的情况，并确保每个应用程序的需求都接收了正确等级水平的可用性。
1.6.4 数据库安全和授权
数据库一旦设计好并部署，程序员和用户就需要访问并修改数据库中的数据。但为防止安全漏洞和不当的数据修改，只有得到授权的程序员和用户才能够访问。DBA的职责是要确保数据只提供给授权用户。
尽管并不尽然（详见“安全的集中化”），但DBA不仅要与DBMS的任意组授权功能打交道，还要通过“SQL GRANT”和“REVOKE”语句与DBMS内部的安全功能打交道。要为数据库环境请求的许多行为进行安全管理：
创建数据库对象，包括数据库、表、视图和程序结构；
变更数据库对象的结构；
访问系统目录；
读取并修改表中的数据；
创建并访问用户定义的功能和数据类型；
运行存储过程；
开始并停止数据库，关联数据库对象；
设置并修改DBMS参数和说明；
运行数据库实用程序，如LOAD、RECOVER和REORG。
数据库安全也可以用其他方式强制执行，例如，创建视图以防止敏感的列与行被终端用户和程序员查看。当外部的安全方法影响数据库安全时，DBA也经常和这些安全方法打交道。
DBA必须了解并能够实施影响数据库访问的任何安全方面。他们应该特别感兴趣的一个领域：SQL注入攻击以及如何预防，这些天曝出了数据泄露的消息。
DBA必须了解影响数据库访问的任何安全方面。
安全的集中化
一些企业已经采取措施，将所有的安全和授权任务、政策和程序，都集中在一个IT安全组。这并不容易实现，正因为如此，相比规模较小的企业，它多见于较大型的企业。
受到严格监管的行业可以选择集中的安全操作。此外，拥有大型计算机的企业往往比那些没有大型计算机的企业更倾向于集中安全。
要成功地将数据库安全的职责从数据库管理团队转移到一个集中的安全团队，这需要给安全人员培训数据库安全有关的技术。此外，许多商家使用的软件从DBMS删除了一些安全操作，并在一个更加传统的安全包（比如，大型计算机上的RACF或ACF2）内模仿相同的功能。
即使考虑所有这些问题，大多数的企业仍然依赖DBA来管理数据库安全。
1.6.5 治理与合规性
确保符合行业和政府法规的要求是数据库管理的一项附加任务，至少在部署适当的控制方面。DBA必须要与管理人员、审计人员和业务专家一起合作来了解适用他们行业的法规及处理数据的方式。
合规性的某些方面是关于标准的DBA作业程序的。例如，法规可能包含执行特定安全和授权程序使用的语言、审计要求、数据备份规范和变更管理程序。然而，要确保合规可能需要严格的文档，或者更高程度的尽职调查或自动化（比如，更深层次的审计跟踪）。
合规性的其他方面，可能需要DBA采用不同的技术、战术和技巧。例如，数据保留法规可能要求数据在使用后仍能存储在一个生产数据库中以长期保留，这就需要数据库有归档的能力；或某些数据可能需要得到保护以免被查看，这就需要数据屏蔽，或在某些情况下设置数据加密。
DBA不应该负责深入地理解任何法规，也不应该设置企业遵守法规的标准。然而，他们会帮助合规项目设置适当的控制及程序，特别是数据处理方面。
DBA为数据处理的合规设置适当的技术控制和程序。
1.6.6 备份和恢复
DBA必须做好准备在问题发生时恢复数据。“问题”可能意味着任何系统故障或程序错误或者一场自然灾害而导致一家企业关闭。现在，大部分数据恢复是应用软件错误和人为错误导致的，硬件故障并不像从前那样普遍了。事实上，分析师的估计表明，80%的应用程序错误是由于软件故障及人为错误。不管什么原因，DBA必须时刻准备着尽快将数据恢复到一个可用的点。
现在，大部分的数据恢复是应用软件错误和人为错误导致的。
面对一次重大停机，通常想到的第一种数据恢复是恢复到当前。数据恢复的最终结果是，该数据库被恢复到发生故障前的状态。在恢复完成之前，应用程序完全不可用。
另一种类型的传统数据恢复是时间点的恢复。时间点的恢复通常用来处理应用程序级别的问题。常规技术执行时间点的恢复将删除指定的时间点以后的所有交易带来的影响。如果在该时间范围内一些有效的交易仍然需要，就会出现时间点后的交易不能恢复的问题。
事务恢复是第三种类型的恢复，解决了传统恢复类型停机时间和有效数据丢失的弊端。因此，事务恢复是一种应用程序恢复，即在指定时间内删除数据库中特定交易所带来的影响。事务恢复有时也称为“应用程序恢复”。
大多数技术人员认为数据恢复是为了解决硬件故障等灾害。虽然硬件故障仍时有发生，但技术人员要做好从这样的故障中恢复的准备，当今大多数数据恢复是源于人为错误或程序自带错误。
DBA必须准备应付所有这些类型的数据恢复。这涉及制订备份策略，以确保数据在软件、硬件或手动操作的错误事件中不丢失。策略必须适用于数据库处理，所以它必须包括数据库文件的映像副本以及数据库日志的备份/恢复计划。它需要考虑同样能影响数据库应用程序的任何非数据库文件的活动。
DBA必须准备应付所有类型的恢复。
1.6.7 确保数据完整性
数据库必须能够以正确的方式存储数据并且不会使数据损坏或破坏。在此过程中，DBA需要利用DBMS的功能实现完整性规则。完整性的三个方面和数据库的讨论相关：物理的完整性、语义的完整性和内部的完整性。
完整性的三个方面和数据库的讨论相关：物理的完整性、语义的完整性和内部的完整性。
物理问题可以使用DBMS的功能，如域和数据类型处理。DBA为每张表的每一列选择适当的数据类型。此操作可确保只有该类型的数据存储在该数据库中，即DBMS强制执行数据类型的完整性。A列定义为整型，则该列只能包含整数。试图在定义为整型的列中存储非数字或者非整数值都将失败。DBA也可以使用约束来进一步划定可以存储在数据库列中的数据类型。大多数相关的DBMS产品提供了以下类型的约束：
参照约束，用于指定定义了表之间的任意关系的列。参照约束用来实现参照完整性，从而确保一张表的一列数据（或一组列）的所有预期的参考，相对于相同或不同表的另一列中的数据是有效的。
唯一约束，确保表中的一列或一组列的值只出现一次。
检查约束，用来在表中的一列或一组列中放置更复杂的完整性规则。检查约束通常使用SQL定义，并可以用来定义一列或一组列允许的数据值。
语义完整性更加难以控制且不易定义。DBA必须准备要执行的策略和方法，以确保他们在数据库中存储的数据是准确的、合适的且可用的。举一个有关语义问题的例子，如数据库中的数据的质量。仅存储任何符合数据库定义的物理完整性的数据是不够的，还要有策略和方法以确保数据的质量。例如，一个客户数据库，其中25%的客户数据含有错误的地址或电话号码，这就是一个质量很差的数据库。没有系统的、物理的方法保证数据的准确性。数据质量要通过适当的应用程序代码、健全的商业惯例和特定的数据政策来保证。冗余是另一个语义问题，如果在整个数据库中数据元素都有冗余，DBA应该如实记录这些问题并找出保证冗余数据同步和准确性的方法。
完整性的最后一个方面是DBMS内部的问题。DBMS依赖内部结构和代码来维护链接、指针和标识符。在大多数情况下，DBMS会很好地维护这些结构，但DBA也需要知道这些情况，以在DBMS失败时知道如何应对。在以下几个方面，内部DBMS的完整性是必不可少的：
索引的一致性。索引是数据库表中数据的有序指针列表。如果由于某种原因，索引与数据不同步，索引访问可能无法返回正确的数据。DBA有检查和纠正这些类型错误的工具。
指针的一致性。有时大型多媒体对象并没有和其他数据一起存储在同一个物理文件中。因此，DBMS需要指针类型的结构，以保持基表数据与多媒体数据同步。强调一下，如果不遵守适当的管理程序，这些指针可能会不同步。
备份的一致性。有些DBMS产品偶尔会接收不恰当的备份副本，实际上这些副本对恢复作用不大。关键是要识别这些情况，并采取相应改正措施。
总而言之，确保数据完整性是DBA的一项必不可少的技能。
