1.1. 数据库的性能取决于两个相互依赖的因素：可用性和响应速度

1.2. 性能包括确保空间的可用性、查询优化以及其他能使数据库以有效的方式返回数据的因素

1.2.1. 如果没有可用性，就无法衡量数据库的性能

1.2.2. 一个不可用的数据库其性能指标为0

1.3. 设置和优化操作系统及应用程序参数

1.4. 管理数据库连接

1.5. 与系统开发人员和网络管理员合作，优化操作系统、网络和事务处理中间件，以方便数据库更好地运行

1.6. 提供合适的存储，让数据库与存储设备和存储管理软件有效配合

1.7. 提供容量增长预测，支持存储获取和一般数据生命周期管理活动，包括保留、调优、存档、备份、清理和灾难恢复

1.8. 与系统管理员一起，提供操作工作负载和基准，以支持SLA管理、收费计算、服务器容量以及规划的生命周期轮换

1.9. 设置数据库性能服务水平

1.9.1. 系统性能、数据可用性、恢复预期以及团队对问题的响应期望，通常是通过IT数据管理服务组织和数据所有者之间的服务水平协议(SLA)来管理的

1.10. 管理数据库可用性

1.10.1. 可用性是指系统或数据库可以用于生产工作的时间百分比

1.10.2. 随着组织增加对数据的使用，可用性需求也增加，不可用数据的风险和成本也随之增加

1.10.3. 可管理性(Manageability)

1.10.3.1. 创建和维护环境的能力

1.10.4. 可恢复性(Recoverability)

1.10.4.1. 中断发生后重新建立服务的能力，修复由于不可预见的事件或组件故障导致的错误的能力

1.10.5. 可靠性(Reliability)

1.10.5.1. 在规定时间内提供指定水平服务的能力

1.10.6. 可维护性(Serviceability)

1.10.6.1. 识别存在问题的能力，诊断原因，修复/解决问题

1.11. 影响数据库的可用性的因素

1.11.1. 计划性停机

1.11.1.1. 出于维护的考虑

1.11.1.2. 出于维护的考虑

1.11.2. 非计划停机

1.11.2.1. 服务器硬件故障

1.11.2.2. 磁盘硬件故障

1.11.2.3. 操作系统故障

1.11.2.4. 数据库软件故障

1.11.2.5. 数据中心站点故障

1.11.2.6. 网络故障

1.11.3. 应用问题

1.11.3.1. 安全和授权问题

1.11.3.2. 严重性能问题

1.11.3.3. 恢复失败

1.11.4. 数据问题

1.11.4.1. 数据损坏（由于缺陷、架构设计或者用户错误）

1.11.4.2. 数据库对象丢失

1.11.4.3. 数据丢失

1.11.4.4. 数据复制问题

1.11.5. 人为错误

1.12. 工具和方法

1.12.1. 运行数据库备份工具

1.12.2. 运行数据库重组工具

1.12.3. 运行统计信息搜集工具

1.12.4. 运行数据完整性检查工具

1.12.5. 自动执行上述这些工具

1.12.6. 利用表空间聚类和分区

1.12.7. 跨库进行数据复制保证高可用性

1.13. 管理数据库运行

1.13.1. DBA部署数据库监控，监视数据库的运行、数据变更日志的使用和复制环境的同步等情况

1.13.2. 日志记录的细节越多，需要的空间和处理进程就越多，这可能会对数据库性能造成负面影响

1.14. 维护数据库性能服务水平

1.14.1. DBA通过性能监控、快速有效响应问题的方式，对数据库性能进行主动和被动的优化

1.14.2. 事务性能与批处理性能

1.14.2.1. 数据移动可能通过在线交易实时发生

1.14.2.2. 许多数据移动和转换活动是通过批处理程序执行的，这些程序可能在系统之间移动数据，或者仅仅对某个系统内的数据执行操作

1.14.3. 问题修复

1.14.3.1. 内存分配和争用。为数据分配缓冲区或缓存

1.14.3.2. 锁与阻塞

1.14.3.3. 不准确的数据库统计信息

1.14.3.3.1. 多数关系型数据库管理系统都有一个内置的查询优化器，它依赖所存储的关于数据和索引的统计信息，从而决定如何最有效地执行给定的查询

1.14.4. 不良代码

1.14.4.1. 数据库性能差的最常见原因可能是SQL编码不良

1.14.4.2. 查询编码人员需要对SQL查询优化器的工作方式有一个基本的了解

1.14.5. 低效而复杂的表连接

1.14.5.1. 使用视图来预先定义复杂的表连接

1.14.5.2. 在数据库函数中避免使用复杂的结构化查询语言（如表连接）

1.14.5.2.1. 与存储过程不同，这些对查询优化器是不透明的

1.14.6. 应用程序活动

1.14.6.1. 在理想情况下，应用程序应该在与数据库管理系统分开的服务器上运行，这样它们就不会争抢资源

1.14.7. 过载的服务器

1.14.7.1. 支持多个数据库和应用程序的数据库管理系统可能存在一个临界点，增加更多的数据库会对现有数据库的性能产生不利影响

1.14.8. 数据库的易变性

1.14.8.1. 在某些情况下，在短时间内大量表的插入和删除会产生不准确的数据库分布统计数据

1.14.9. 失控的查询语句

1.14.9.1. 用户可能会无意识地提交了一个占用大部分共享资源的查询

1.15. 维护备用环境

1.15.1. 数据库并非是一旦建成就永不改变的

1.15.2. 随着业务规则更改、业务流程更改和技术更改，开发和测试环境允许在变更被带入生产环境之前进行更改测试

1.15.3. 开发环境

1.15.3.1. 用于创建和测试将在生产中执行的更改

1.15.3.2. 尽管资源配置有所缩减，开发必须与生产环境保持紧密的联系

1.15.4. 测试环境

1.15.4.1. 测试环境有几种用途，如质量保证、集成测试、用户验收测试和性能测试

1.15.5. 数据沙箱

1.15.5.1. 实验环境被用来检验假设及开发新的数据使用

1.15.5.2. DBA通常要设置、授予沙箱的访问权限，并监视这些环境的使用情况

1.15.5.3. 确保沙箱是隔离的，不会对生产操作产生不利影响

1.15.6. 备用的生产环境

1.15.6.1. 是被用来支持脱机备份、故障转移和韧性支持的系统

2.1. 软件测试是劳动密集型的活动，占近一半的系统开发成本

2.2. 有效的测试需要高质量的测试数据，并且必须对这些数据进行管理

2.3. 测试数据的生成是软件测试中的一个关键步骤

2.3.1. 测试数据是专门用于测试系统的

2.3.2. 测试可以验证给定的输入集产生的预期输出，或者检测编程对异常、极端或意外输入的响应能力

2.3.3. 测试数据可以是完全虚构的，也可以用无意义的值生成，也可以是样本数据

2.3.3.1. 样本数据可以是实际生产数据的子集（内容或结构的），也可以从生产数据中生成

2.3.3.2. 根据需要，可以对生产数据进行筛选或聚合创建多个示例数据集

2.3.3.3. 如果生产数据报含受保护或受限制的数据，那么样本数据必须与外界隔离

2.3.4. 测试数据可以集中产生，也可以用系统的方式（通常是功能测试的情况下）使用统计或过滤器来生成，或者使用其他不太集中的方法（通常是在高容量随机自动化测试的情况下）

2.3.5. 测试数据可以由测试人员、辅助测试人员的程序与功能产生，也可由选择和筛选的生产数据副本产生

2.3.6. 测试数据可以作为短期重新使用的数据而保存，用来创建和管理支持回归测试，或者数据一次性使用后删除

2.3.6.1. 定期清除旧的测试数据以保留数据库容量

2.4. 某些测试（特别是性能测试）并不总是能够产生足够的测试数据

2.4.1. 要生成的测试数据的数量是由时间、成本和质量等因素决定或限制的，同时还受到在测试环境中使用生产数据的规章制度影响

3.1. 数据迁移是在尽可能不改变数据的情况下，在不同存储类型、格式或计算机系统之间传送数据的过程

3.2. 数据迁移对于任何系统实施、升级或合并，都是需要考虑的关键因素

3.2.1. 通常基于规则采用事先编好的程序自动执行

3.3. 数据迁移的原因有很多，包括服务器或存储设备替换、升级、网站整合、服务器维护或数据中心迁移

3.3.1. 大多数迁移工作在执行的时候允许以一种非破坏性的方式进行

3.4. 映射的粒度决定了元数据的更新速度，决定了迁移过程中需要多少额外的磁盘容量，决定了先前位置被标记为空闲的速度

3.4.1. 粒度越小意味着更新速度越快，所需空间越小，释放旧存储越快

3.5. 将过度使用的存储设备上的数据转移到一个单独的环境中

3.6. 根据需要将数据移动到速度更快的存储设备上

3.7. 实施数据生命周期管理策略

3.8. 将数据从旧的存储设备（无论是报废还是停止租赁）迁移到线下或云存储上

3.9. 通常会执行自动和手动的数据修复，以提高数据的质量、消除冗余或过时的信息，并适应新系统的需求

3.10. 中等或高度复杂的应用程序数据（设计、提取、修复、加载、验证）迁移到新系统部署之前，通常需要重复演练多次

4.1. 数据建模工具

4.1.1. 数据建模工具可以帮助数据建模人员自动化执行许多任务

4.1.2. 生成数据库数据定义语言脚本(DDL)

4.1.3. 从数据库到数据模型进行逆向工程

4.1.4. 验证命名标准、检查拼写、存储元数据（定义和血缘关系），甚至可以发布信息到网站上

4.2. 数据库监控工具

4.2.1. 数据库监控工具自动监控关键指标（如容量、可用性、缓存性能、用户统计等），并向DBA和网络存储管理员发出当前数据库问题报警

4.2.2. 同时监控多种类型的数据库

4.3. 数据库管理工具

4.3.1. 配置功能、安装补丁和升级、备份和恢复、数据库克隆、测试管理和数据清理任务

4.4. 开发支持工具

4.4.1. 包含一个可视化界面，用于连接和执行数据库上的命令

5.1. 在低阶环境中测试

5.1.1. 在最低阶配置的环境中安装和测试——通常是开发环境

5.1.2. 在最低阶环境中测试后，再在下一阶的环境继续验证，最后安装部署到生产环境中

5.1.3. 可以让安装人员积累升级或修复补丁的经验，并且可以确保对生产环境的影响最小

5.2. 物理命名标准

5.2.1. 命名的一致性有助于加快理解的速度

5.2.2. 定义元数据或创建不同组织之间交换文件的规则

5.2.3. 元数据注册表(Metadata Registries, MDR)处理数据的语义、数据的表示和数据描述的注册

5.3. 所有变更操作脚本化

5.3.1. 由于请求的“一次性”以及缺乏适当的工具，直接更改数据库中的数据是非常危险的

6.1. 数据丢失的风险

6.1.1. 由于技术或程序错误，或者出于恶意的目的，数据可能会丢失

6.1.2. 正在进行的评估需要确保强有力的技术支持，以防止恶意目的造成的数据丢失

6.1.3. 随着网络威胁的不断演变，建议进行SLA审计和数据审计来评估和规划风险缓解措施

6.2. 与技术准备有关的风险

6.2.1. 需要IT技能和经验准备

6.2.2. 必须做好发挥这些技术在商务智能及其他应用领域作用的准备

6.3. 组织和文化变化

6.3.1. DBA往往不能有效地提升自身工作对组织的价值

6.3.2. 把数据工作看作是一系列原则和实践的抽象集合，无视参与者的人为因素，传播“我们vs.他们”的对立心态，这会给工作制造障碍，对工作没有任何帮助

6.3.3. 大量断层主要是由于参考框架中的冲突所导致的

6.3.3.1. 组织是从特定的应用程序角度看待信息技术，而不是从数据角度，通常是以应用程序为中心的角度来看待数据

6.3.4. 在应用程序开发时，常常将数据管理视为应用程序开发的一个障碍，认为它使得项目开发的时间更长、成本更高，而且并没有带来其他的好处

6.3.5. 良好的数据管理实践能够帮助他们实现对象和应用程序重复使用的长期目标，以及真正面向服务的应用程序架构

6.3.6. 通过遵循指导原则来识别和采取行动，在考虑重用的情况下进行构建，应用最佳实践，将数据库标准与支持联系起来，从而促进一种更有用和协作的方法来满足组织的数据和信息需求，并设定DBA在项目工作中的预期目标

6.3.7. 主动沟通

6.3.7.1. DBA在开发期间和开发完成后，都应与项目团队密切沟通，尽早发现并解决问题

6.3.7.2. 审查开发团队编写的数据访问代码、存储程序、视图和数据库函数，并帮助解决数据库设计中的问题

6.3.8. 站在对方的立场上与之沟通

6.3.9. 保持专注于业务

6.3.9.1. 应用程序开发的目标是满足业务需求并从项目中获得最大的价值

6.3.10. 对他人要有帮助

6.3.10.1. 总是对他人说“不”会导致对方忽略标准，另谋他路

6.3.10.2. 每个人都需要完成自己分内的工作，但是在他人成功的道路上不施以援手对彼此都不利

6.3.11. 不断学习

6.3.11.1. 评估在项目实施中遇到的挫折，吸取教训，以规避再次出现类似的问题

6.3.12. 要了解利益相关方及其需求，制定清晰、简明、实用、以业务为中心的标准，尽可能以最好的方式完成工作

7.1. 数据存储的度量指标

7.1.1. 数据库类型的数量

7.1.2. 汇总交易统计

7.1.3. 容量指标

7.1.4. 已使用存储的数量

7.1.5. 存储容器的数量

7.1.6. 数据对象中已提交和未提交块或页的数量

7.1.7. 数据队列

7.1.8. 存储服务使用情况

7.1.9. 对存储服务提出的请求数量

7.1.10. 对使用服务的应用程序性能的改进

7.2. 性能度量评估指标

7.2.1. 事务频率和数量

7.2.2. 查询性能

7.2.3. API服务性能

7.3. 操作度量指标

7.3.1. 有关数据检索时间的汇总统计

7.3.2. 备份的大小

7.3.3. 数据质量评估

7.3.4. 可用性

7.4. 服务度量指标

7.4.1. 按类型的问题提交、解决和升级数量

7.4.2. 问题解决时间

8.1. 确保数据库遵守所有许可协议和监管要求

8.2. 对软件使用许可、年度支持费用以及服务器租赁协议和其他固定费用，进行仔细跟踪和年度审计

8.3. 不遵守许可协议会给组织带来严重的财务和法律风险

8.4. 审计数据可以帮助确定每种技术和产品的总拥有成本(TCO)

8.5. 定期评估那些过时、过保、用处不大或太昂贵的技术和产品

9.1. 数据审计是根据定义的标准对数据集进行评估的过程，通常是对数据集的特定关注点进行审计

9.2. 审计的目的是为了确定数据的存储是否符合合同和方法要求

9.3. 数据审计方法可能包括一个项目特定和全面的检查表、所需的可交付成果和质量控制标准

9.4. 数据验证是根据既定的验收标准评估存储数据的过程，以确定其质量和可用性

9.5. 数据验证程序依赖于数据质量团队（如果该团队存在）或其他数据使用者的需求所建立的标准

9.6. 帮助制定和审查方法

9.7. 进行初步的数据筛选和审查

9.8. 开发数据监控方法

9.9. 应用统计信息、地理统计信息、生物统计信息等技术来优化数据分析

9.10. 支持采样及分析

9.11. 审核数据

9.12. 提供数据发现的支持

9.13. 担任与数据库管理相关问题的主题专家