读DAMA数据管理知识体系指南16数据存储和操作活动

1. 活动

1.1. 数据存储和操作包括数据库技术支持和数据库操作支持两个主要活动

1.2. 数据库技术支持侧重选择和维护用于存储和管理数据的软件

1.3. 数据库操作支持侧重软件所管理的数据和进程

2. 管理数据库技术

2.1. 技术管理的主要参考模型是信息技术基础设施库(ITIL)

• 2.1.1. ITIL是英国开发的一种技术管理过程模型，其原则对数据库管理技术同样适用

2.2. 理解数据库的技术特征

• 2.2.1. 理解技术是如何工作的，以及它在特定业务环境中如何提供价值是非常重要的

• 2.2.2. DBA与其他数据服务团队一起，同业务用户及其主管密切合作，以便了解业务的数据和信息需求

• 2.2.3. 数据专业人员必须先理解候选数据库技术的特点，然后才能确定将哪种技术推荐为解决方案

• 2.2.4. 不能假设单一类型的数据库架构或数据库管理系统可以满足所有业务需求

  • 2.2.4.1. 大多数组织都安装了多种数据库工具，完成从性能优化、备份，到数据库自身管理的一系列功能

2.3. 评估数据库技术

• 2.3.1. 选择战略性的数据库管理系统(DBMS)软件非常重要

• 2.3.2. 考虑因素

  • 2.3.2.1. 产品架构和复杂性

  • 2.3.2.2. 容量和速度限制，包括数据流传送速率

  • 2.3.2.3. 应用类别，如事务处理、商务智能、个人资料

  • 2.3.2.4. 特殊功能，如时间计算支持

  • 2.3.2.5. 硬件平台及操作系统支持

  • 2.3.2.6. 软件支持工具的可用性

  • 2.3.2.7. 性能评测，包括实时统计信息

  • 2.3.2.8. 可扩展性

  • 2.3.2.9. 软件、内存和存储需求

  • 2.3.2.10. 韧性，包括错误处理和错误报告

• 2.3.3. 与技术本身没有直接关系的因素

  • 2.3.3.1. 组织对技术风险的偏好

  • 2.3.3.2. 提供训练有素的技术专业人员

  • 2.3.3.3. 拥有成本，如软件许可费、维护费和计算资源成本

  • 2.3.3.4. 供应商声誉

  • 2.3.3.5. 供应商支持策略和版本计划

  • 2.3.3.6. 其他客户案例

• 2.3.4. 产品的费用，包括维护管理费用、许可费用和技术支持费用，不应超过产品对企业的价值

  • 2.3.4.1. 在理想情况下，技术（产品）应该尽可能方便用户、自我监控和自我管理

  • 2.3.4.2. 如果不能做到这点，那就有必要引入熟练使用相关工具的员工

2.4. 管理和监控数据库技术

• 2.4.1. DBA通常是作为后台技术支持与服务台和供应商的支持人员一起，理解、分析和解决用户问题

  • 2.4.1.1. DBA应具备应用程序开发的相关知识，如数据建模、用例分析和应用程序的数据访问方式

  • 2.4.1.2. DBA要确保定期给数据库做备份，同时还要做恢复测试

• 2.4.2. 当某项业务需要使用新技术时，DBA要与业务用户和应用程序开发人员合作，确保最有效地使用该技术，探索该技术的新应用，并解决使用过程中出现的任何问题

• 2.4.3. 要想有效理解和使用某种技术，关键在于培训

  • 2.4.3.1. 各组织应确保为参与实施、支持和使用数据和数据库技术的每个人制订培训计划并预留预算

  • 2.4.3.2. 培训计划应包括适当级别的交叉培训，以更好地支持应用程序开发，尤其是敏捷开发

3. 管理数据库操作

3.1. DBA和网络存储管理员提供的数据库支持是数据管理的核心

3.2. 数据库部署在托管存储区域中

• 3.2.1. 托管存储可以小到个人计算机上的磁盘驱动器（由操作系统管理）​，也可以大到存储区域网络(SAN)上的RAID阵列

• 3.2.2. 备份介质也属于托管存储

4. 理解需求

4.1. 定义存储需求

• 4.1.1. DBA为数据库管理系统(DBMS)应用程序建立存储系统，为NoSQL建立文件存储系统

• 4.1.2. 网络存储管理员和DBA在建立文件存储系统方面都发挥着重要作用

• 4.1.3. 在正常的业务运营中，数据存入存储介质，取决于是要永久性存放还是临时性存放

• 4.1.4. 在真正提供存储空间之前，做好增加额外空间的规划是很重要的

  • 4.1.4.1. 所有项目都应该作第一年运营的初始容量估算，以及未来几年内的空间增长预测

  • 4.1.4.2. 不要只考虑数据自身所需空间，还要考虑索引、日志以及其他任何的冗余特征，如镜像(Mirror)

• 4.1.5. 紧急情况下的任何维护操作都是危险的

• 4.1.6. 数据存储需求必须考虑与数据保留相关的法规

  • 4.1.6.1. 出于合规考虑，组织需要保留特定时间周期的一些数据

4.2. 识别使用模式

• 4.2.1. 基于事务型

• 4.2.2. 基于大数据集的读或写型

• 4.2.3. 基于时间型（月末压力大、周末压力轻等）​

• 4.2.4. 基于位置型（人口集中的地区有更多交易等）。

• 4.2.5. 基于优先级型（某些部门或者某些批处理相对有更大权限的优先级）

• 4.2.6. DBA要能够预测使用模式的起伏转换，并有应对高峰期（如查询管理或优先级管理）​，以及利用低谷期（将需要大量资源的操作过程延迟到低谷期执行）的适当的流程

4.3. 定义访问需求

• 4.3.1. 数据访问包括与存储、获取或者处理存储在其他数据库和资料库中的数据等相关的活动

• 4.3.2. 数据访问就是授权访问不同数据文件的过程

• 4.3.3. 数据架构师和DBA有义务为组织选择合适的数据访问方法和工具

5. 规划业务连续性

5.1. 组织需要为灾难事件、影响系统或影响使用数据的不利事件进行业务连续性规划(Plan for Business Continuity)

5.2. DBA必须确保所有数据库和数据库服务器都有恢复计划，包括可能导致数据丢失或数据损坏的场景

• 5.2.1. 物理数据库服务器失效

• 5.2.2. 一块或多块磁盘存储设备失效

• 5.2.3. 数据库失效，包括主要的数据库、临时的存储数据库和事务日志等

• 5.2.4. 数据库索引或数据页损坏

• 5.2.5. 数据库和日志段的文件系统失效

• 5.2.6. 数据库或事务日志的备份文件失效

  • 5.2.6.1. 如果备份不可用或不可读，则无法从灾难中恢复任何系统

  • 5.2.6.2. 定期备份对于任何恢复工作都是必不可少的，但如果备份不能被读取，那比没有备份可用还糟糕

  • 5.2.6.3. 那些不可读备份的处理时间不仅被浪费了，而且还错失了修复不可读备份的机会

  • 5.2.6.4. 要将所有的备份保存在远离生产现场的安全位置

5.3. 应该评估每个数据库的重要性，以此确认恢复的优先顺序

• 5.3.1. 在主要系统启动和正常运行之前，不太重要的数据库不会投入精力去恢复

• 5.3.2. 一些系统可能根本不需要做恢复

5.4. 管理层和组织的业务连续性管理团队（如果有的话）应审查和批准数据恢复计划

• 5.4.1. DBA团队应定期审查计划的准确性和全面性

5.5. 备份数据

• 5.5.1. 如果对数据库做备份，条件允许的话，还要对数据库事务日志做备份

• 5.5.2. 对大型数据库来说，过快的备份频率会消耗大量的存储空间和服务器资源

• 5.5.3. 除了增量备份之外，应定期对每个数据库进行全库备份

• 5.5.4. 在理想情况下，存储在存储区域网络(SAN)的RAID阵列上，每天再备份到独立的存储介质

• 5.5.5. 对于OLTP类型的数据库，事务日志的备份频率取决于数据更新的频率和涉及的数据量

• 5.5.6. 对于频繁更新的数据库，更频繁的日志转储不仅可以提供更大的保护，还可以减少备份对服务器资源和应用程序的影响

• 5.5.7. 备份文件应该与数据库分开，存放到不同的文件系统中

  • 5.5.7.1. 应该要求备份到单独的存储介质中

  • 5.5.7.2. 每天备份的副本应该存储在安全且远离生产系统的场所中

  • 5.5.7.3. 大多数DBMS支持对数据库进行热备份——在应用程序运行时进行的备份

5.6. 恢复数据

• 5.6.1. 大多数备份软件都有从备份中读取并恢复到系统的功能

• 5.6.2. 文件型数据库中的数据比关系型数据库管理系统中的数据更容易恢复

• 5.6.3. 如果是从日志中恢复而不是从备份中恢复，那么关系型数据库管理系统在恢复的过程中还需要更新目录(Catalog)信息

• 5.6.4. 定期进行数据库的恢复测试是非常重要的

  • 5.6.4.1. 可以减少灾难或紧急情况下发生意外

• 5.6.5. 恢复测试可以在具有相同基础架构和配置的非生产系统的副本环境上进行

• 5.6.6. 如果系统有“故障切换”环境，那么恢复测试可以在辅助系统上进行

6. 创建数据库实例

6.1. 安装和更新DBMS软件

6.2. 维护多种环境的安装，包括不同的DBMS版本

• 6.2.1. DBA可以在沙盒环境、开发环境、测试环境、用户验收测试(UAT)环境、系统验收测试环境、质量保证环境、预生产环境、热修复(Hot-Fix)环境、灾难恢复环境和生产环境中安装和维护DBMS软件的多个实例，并管理与应用程序版本、系统版本变更相关的DBMS软件版本的升级迁移

6.3. 安装和管理相关的数据技术

• 6.3.1. 物理存储环境管理

  • 6.3.1.1. 物理存储环境管理需要遵循传统的软件配置管理(SCM)过程或信息技术基础设施库(ITIL)的方法，以记录对数据库配置、结构、约束、权限、阈值等的修改

  • 6.3.1.2. 通过敏捷开发和极限编程思想，物理数据模型的更新在防止设计或开发错误方面发挥着重要作用

  • 6.3.1.3. SCM过程

    6.3.1.3.1. 配置识别

    6.3.1.3.1.1. 在配置识别过程中，DBA将与数据专员、数据架构师和数据建模师一起明确为终端用户所定制的各个方面的属性配置

    6.3.1.3.2. 配置变更控制

    6.3.1.3.2.1. 它是一组用于更改配置项属性并重新对其进行基线化的流程和审批阶段

    6.3.1.3.3. 配置状态报告

    6.3.1.3.3.1. 及时记录和报告任意点上与每个配置项相关的配置基线

    6.3.1.3.4. 配置审计

    6.3.1.3.4.1. 它发生在交付和发生变更的时候

    6.3.1.3.4.2. 物理配置审计是确保配置项按照其详细设计文档的要求进行安装

    6.3.1.3.4.3. 功能配置审计是确保配置项的性能属性得以实现

  • 6.3.1.4. 在整个数据生命周期中，为了保持数据的完整性和可追溯性，DBA将这些变更同步给建模人员、开发人员和元数据管理人员

• 6.3.2. 管理数据访问控制

  • 6.3.2.1. 受控环境

    6.3.2.1.1. DBA与网络存储管理员合作管理数据资产的受控环境，包括网络角色和权限管理、全天候监控和网络健康监控、防火墙管理、补丁管理和微软基准安全分析器(MBSA)集成管理

  • 6.3.2.2. 物理安全

    6.3.2.2.1. 数据资产的物理安全性由基于简单网络管理协议(SNMP)的监控、数据审计日志记录、灾难管理和数据库备份计划进行管理的

    6.3.2.2.2. DBA配置且监视这些协议

    6.3.2.2.2.1. 监控对于安全协议尤其重要

  • 6.3.2.3. 监控

    6.3.2.3.1. DBA通过对关键服务器进行连续的硬件和软件监控，来实现数据库系统的可用性

  • 6.3.2.4. 控制

    6.3.2.4.1. DBA通过访问控制、数据库审计、入侵检测和漏洞评估工具来维护数据安全

• 6.3.3. 创建存储容器

  • 6.3.3.1. 所有的数据存储在一个物理设备上并被进行组织，以便加载、查询或检索

  • 6.3.3.2. 存储容器本身可能包含存储对象，并且每个级别都必须与该对象的级别相适合

• 6.3.4. 应用物理数据模型

  • 6.3.4.1. DBA负责创建和管理完整的物理数据存储环境，而数据存储环境通常是以物理数据模型为基础

  • 6.3.4.2. 物理数据模型包括存储对象、索引对象以及执行数据质量规则、连接数据库对象以及实现数据库性能所需的任何封装代码对象

  • 6.3.4.3. 当DBA提供数据服务(Data-as-a-Service, DaaS)时，更有必要维护良好的物理模型

• 6.3.5. 加载数据

  • 6.3.5.1. 一些数据的获取需要法律许可，因此在加载数据之前，DBA需要注意这些限制

  • 6.3.5.2. 另外一种数据采集的管理方法是将数据订阅服务的责任集中在数据分析人员上

    6.3.5.2.1. 数据分析人员需要在逻辑数据模型和数据字典中记录外部数据源

• 6.3.6. 管理数据复制

  • 6.3.6.1. 主动或被动复制

  • 6.3.6.2. 基于分布式数据系统的分布式并发控制

  • 6.3.6.3. 在数据更改控制过程中，通过时间戳或版本号来识别数据更新的适当方法

  • 6.3.6.4. 对于小型系统或数据对象来说，完整的数据刷新可以满足并发的要求

  • 6.3.6.5. 于较大的数据对象来说，如果大多数的数据不必更改，则将更改合并到数据对象中比每次更改时完全复制所有数据更有效率

  • 6.3.6.6. 如果大型数据对象的大部分数据要被更改的话，那么频繁更新会带来很多花销

    6.3.6.6.1. 进行刷新可能是更好的选择