思维导图

6.1 引言

        数据存储与操作包括对存储数据的设计、实施和支持，最大化实现数据资源的价值，贯穿于数据创建/获取到处置的整个生命周期。

6.1.1 业务驱动因素

        数据存储与操作活动对于依赖数据的企业来说非常关键，这些活动的主要驱动因素是业务连续性。

6.1.2 目标和原则

目标：

• 在整个数据生命周期中管理数据的可用性。
• 确保数据资产的完整性。
• 管理数据交易事务的性能。

原则：

• 识别自动化的机会并采取行动
• 构建时就考虑重用的思想
• 理解并适当使用最佳实践
• 支持数据库的标准需求
• 为项目中的DBA角色设置期望值

6.1.3 基本概念

1、数据库术语

数据库

不论其结构和内容如何，数据库是存储数据的集合。一些大型数据库也称为“实例(Instance)”或“模式(Schema)”。

实例

通过数据库软件，执行对某一特定存储区域的控制访问。一个组织通常使用不同的存储区域，同时执行多个实例。每个实例与所有其他实例相互独立。

模式

模式是数据库或实例中的数据库对象的一个子集(Subset)。模式 被用来将数据库对象组织成多个可管理的集合。通常，一个模式拥有一 个用户以及访问该模式内容的特定访问列表。模式的常见用法是将包含 敏感数据的对象与普通用户群隔离，或者是在关系数据库中将只读视图 与基础表隔离。模式还可以表示具有相似性的数据库结构的集合。

节点

一台单独的计算机作为分布式数据库处理数据或者存储数据的一个部分。

数据库抽象

通用应用接口(API)通常用来调用数据库函数。这样，一个应用可以连接到多个不同数据库，而开发者不必知道所有函数可能调用了哪些数据库。ODBC(Open Database Connectivity)是支持数据库抽象的一个API示例。数据库抽象的优势是可移植性很强，缺点是对于某些针对特定数据库的函数，就很难跨库使用了。

2、数据生命周期管理

        贯穿数据设计、实现到使用(任何系统存储、处理和检索数据)的整个数据生命周期，DBA都有责任维护和确保数据的准确性和一致性。DBA是所有数据库变更的监管人。 

        数据生命周期管理包括为数据的获取、迁移、保留、过期和处置进行的实施策略和过程。

3、管理员

        数据库管理员(DBA)是数据专业中最常见、也是最广泛被接纳的角色。

        DBA不是独立完成数据存储和操作所有相关活动的唯一角色。数据管理专员、数据架构师、网络管理员、数据分析师和安全分析师也要参与数据性能、保留和恢复的规划。

4、数据架构类型

        数据库可以分为集中式数据库和分布式数据库集中式系统管理单一数据库，而分布式系统管理多个系统上的多个数据库。分布式系统组件可以根据组件系统的自治性分为两类：联邦的(自治的)或非联邦的 (非自治的)

集中式数据库：

        集中式数据库将所有数据存放在一个地方的一套系统中，所有用户连接到这套系统进行数据访问。对某些访问受限的数据来说，集中化可能是理想的，但对于需要大范围、广泛使用的数据来说，集中式数据库可能存在风险。例如，如果集中式数据库不可用，就没有其他途径能访问到数据。

分布式数据库：

多节点、高效、高可用、横向扩展

联邦数据库：（底层数据分布在不同系统）

        数据联邦提供的数据不需要对数据源进行额外复制或持久化。联邦数据库系统地将多个自治的数据库系统映射成一个单一的联邦数据库 (图6-3)。组成联邦的数据库有时是分散在不同地理位置，通过计算机网络关联在一起。他们保留本地的自治操作，同时参与到一个联邦 中，允许部分和受控地共享他们的数据。数据联邦提供了合并不同数据库的一种替代方法。

        联邦数据库对于类似企业信息集成、数据可视化、模式匹配和主数据管理这样异构和分布式的集成项目非常合适。

        根据组成联邦的组件数据库系统的级别和联邦提供的扩展服务的不同，联邦架构也会有所不同。联邦数据库管理系统可以分为松耦合和紧耦合两类。

区块链数据库：

        区块链数据库属于一种联邦数据库，用于安全管理金融交易。它们也能用来进行合同管理或健康信息交换。区块链数据库有两种结构类 型：单条记录和块。每个交易包含一条记录，每个区块包含一组带时间戳的交易，整个数据库由多个区块形成的链状结构组成，每个区块还包括链中前一个区块的信息。

可视化/云计算平台：

• 虚拟机镜像
• 数据库即服务(DaaS)
• 管理托管在云上的数据库

DBA需要与网络和系统管理员协调，建立系统的项目集成机制，包括标准化、整合、虚拟化、数据自动备份与恢复以及数据安全，即:

• 标准化/整合
• 服务器虚拟化
• 自动化
• 安全

5、数据处理类型

数据库处理有两种基本类型:ACID和BASE

ACID

含义是保证数据库事务可靠性不可或缺的约束。在关系型数据库存储中，ACID相关技术是最主要的工具，通常采用SQL作为接口。

• 原子性(Atomicity)。所有操作要么都完成，要么一个也不完成。因此，如果事务中的某部分失败，那么整个事务就都会失败。
• 一致性(Consistency)。事务必须时刻完全符合系统定义的规则，未完成的事务必须回退。
• 隔离性(Isolation)。每个事务都是独立的。
• 持久性(Durability)。事务一旦完成，就不可撤销。

BASE（大数据）

        数据增长规模空前，数据新增种类繁多。记录和存储非结构化数据 的需要，读优化和数据负载性能需要以及后续在横向扩展、设计、处 理、成本及灾难恢复方面有更大灵活性的需要等，这些都走向了与 ACID正好相反的一方。BASE应时而生，满足了这些需要。

• 基本可用(Basically Available)。即使节点发生故障，系统仍然能保证一定级别数据的可用性。数据可能过时，但系统仍然会给出响应。
• 软状态(Soft State)。数据处于持续流动的状态，当给出响应时，数据不保证是最新的。
• 最终一致性(Eventual Consistency)。数据在所有节点、所有数据库上最终状态是一致的，但并非每时每刻在每个事务里都是一致的。

ACID和BASE的区别

事项	ACID	BASE
数据结构	模式必须存在	动态的
	表结构必须存在	在运行中调整
	列数据的类型是确定的	存储不同类型的数据
一致性	强一致性可用	强一致性、最终一致或不追求一致性
处理焦点	事务	键值存储
处理焦点	行/列	宽列存储
历史	20世纪70年代末期开始，应用存储	2000年，非结构化存储
扩展	依赖产品	在商业服务器间自动传播数据
来源	混合（商业和开源）	开源
事务	是	可能

CAP

        CAP定理(也称为“布鲁尔定理”)是集中式系统在朝着分布式的系 统方向发展过程中提出的理论。CAP定理指的是分布式系统不可能同时满足ACID的所有要求。系统规模越大，满足的要求点越少。分布式系统必须在各种属性(要求)间进行权衡。

• 1)一致性(Consistency)。系统必须总是按照设计和预期的方式 运行。
• 2)可用性(Availability)。请求发生时系统时刻都保持可用状 态，并对请求作出响应。
• 3)分区容错(Partition Tolerance)。偶尔发生数据丢失或者部分系统故障发生时，系统依然能够继续运行提供服务。

CAP定理指出，在任何共享数据的系统里，这3项要求最多只可能 同时满足其中两项。通常用“三选二”来说明

6、数据存储介质

• 磁盘和存储区域网络(SAN)
• 内存
• 列压缩方案
• 闪存

7、数据库环境

• 生产环境
• 非生产环境
  • 开发环境
  • 测试环境
• 数据沙盒或实验环境

8、数据库组织模型

        数据库通常以3种形式进行组织：层次型、关系型和非关系型，这种归类 并非是完全互斥的(图6-6)。一些数据库系统可以同时读写以关系型和非关系型结构组织的数据。层次型数据库可以映射成关系型表结构。

层次型数据库

        层次型数据库(Hierarchical Database)是最古老的数据库类型，在早期的大型数据库管理系统中使用，它的结构要求最为严格。在层次型数据库中，数据被组织成具有强制的父子关系的树型结构：每个父级可以有多个子级，但每个子级只有一个父级(也称为一对多关系)。目录树是层次数据库的一个示例。XML使用的也是层次模型，尽管实际的结构是树的遍历路径，但可以表示成关系数据库。

关系型数据库

        要写入数据，必须提前知道表的结构(模式)，所以称之为“写入时进行处理的模式”。关系型数据库是面向行(Row)的。

        关系型数据库管理系统被称为RDBMS。当需要存储的数据不断变化时，关系型数据库是主要选择。关系型数据库的变体包括多维数据库和时态数据库。

1)多维数据库。

        多维数据库(Multidimensional Database)技术将数据存储在一种数据结构中，它允许同时对多个数据元素过滤器进行搜索。这种类型的结构最常用于数据仓库(DW)和商务智能(BI)。尽管大多数大型数据 库都有作为对象内置的多维数据集技术，但其中一些数据库类型是专有的。多维数据库对数据的访问使用的是SQL的一个变体多维表达式 (Multidimensional eXpression，MDX)。

2)时态数据库。

        时态数据库(Temporal Database)是一种内置了支持处理涉及时间数据的关系型数据库。面向时间的特性通常包括有效时间和事务时间。 这些特性可以组成双时态数据模型。

        1 有效时间。现实世界中一个真实事件或实体对象发生的时间范 围。

        2 事务时间。存储在数据库中的事实被认为是真实的时间段。 数据库中可能包含除了有效时间和事务时间之外的时间线，如决策时间。对应双时态数据库，这种情况被称为多时态数据库。时态数据库让应用开发人员和DBA在同一个数据库中管理数据当前、将来和历史的多个版本。

非关系型数据库

列式数据库：

选择面向列的数据库(非关系的)和面向行的数据库(通常是关系 型的)需要进行权衡:

1. 当需要对很多行进行聚合计算时，面向列的存储组织方式会更加高效。这只适用于处理少数列的情况，因为读取少数列比读取所有列的数据更快。
2. 当一次向所有行更新某个列时，面向列的存储组织更加高效，因为可以不必访问行里的其他列就有效地写入数据，替换旧的列数据。
3. 当同时需要获取一行中的许多列，并且行的体量相对较小，单次磁盘访问就能将整行数据检索时，面向行的存储组织更加高效。
4. 如果写入一条新纪录时同时要提供所有的行数据，那么面向行的组织效率更高；整个行的数据可以用单次磁盘操作写入。
5. 在实践中，面向行的存储布局非常适合于在线事务处理 (OLTP)类的工作负载，此类负载的重点是交互式事务。面向列的存储布局非常适合于在线分析处理(OLAP)类的工作负载。例如，数据仓库通常涉及对所有数据(可能有千兆字节大小)的少量高度复杂的查 询。

空间数据库：

        空间数据库可以执行各种各样的空间操作。根据开放地理空间联盟标准，空间数据库可以执行以下一个或多个操作:

1. 空间评估(Spatial Measurements)。计算线条长度、多边形面 积、几何图形之间的距离等。
2. 空间功能(Spatial Functions)。修改现有特征以创建新特征。例如，在空间周围提供缓冲区、相交特征等。
3. 空间预测(Spatial Predicate)。允许对几何图形之间的空间关系进行真假查询。例如，两个多边形重叠吗？拟建垃圾填埋场附近1000米范围内是否有住宅？
4. 几何构造(Geometry Constructors)。通常通过描述所定义形状的顶点(点或节点)来创建新的几何图形。
5. 观测功能(Observer Functions)。查询并返回某个特征的特定信息。例如，圆心的位置。

对象/多媒体数据库。

        多媒体数据库(Multi-media Database)包括一个分层存储管理系统，用于高效管理磁介质和光存储介质。它还包括表示系统基础对象的集合。

平面文件数据库。

        平面文件数据库(Flat File Database)描述了将数据集编码为单个文件的各种方法。平面文件可以是纯文本文件或二进制文件。严格来说，平面文件数据库只包含数据以及长度和分隔符不同的记录。更广泛地说，这个术语是指以行和列的形式存在于单个文件中的任何数据库， 除此之外，记录和字段之间没有任何关系或链接。纯文本文件通常每行包含一条记录。手写在纸上的姓名、地址和电话号码列表就是平面文件 数据库的一个示例。平面文件不仅用作数据库管理系统的数据存储工 具，还用作数据传送工具。Hadoop数据库使用平面文件做数据存储。

键值对。

键值对数据库(Key-Value Pair Database)的数据项包含两个部分:

键的标识符和值。这类数据库有许多特定的用法:

1. 文档数据库(Document Databases)。面向文档的数据库包含由结构和数据组成的文件集合。每个文档都分配了一个键。更高级的面向文档的数据库还可以存储文档内容的属性，如日期或标记。这种类型的数据库可以存储完整或不完整的文档。文档数据库可以使用XML或 JSON(Java脚本对象注释)结构。
2. 图数据库(Graph Databases)。图数据库存储关键值对，关注的重点是组成图的节点关系，而不是节点本身。

三元组存储

三元组存储大致可以分为三类：原生三元组存储、RDBMS支持的 三元组存储和NoSQL三元组存储。

1. 1原生三元组存储(Native Triplestores)。那些从零开始实现并利用RDF数据模型来高效地存储和访问RDF数据的三元组存储。
2. RDBMS支持的三元组存储(RDBMS-backed Triplestores)。在现有的RDBMS之上添加RDF描述层构建的三元组存储。
3. NoSQL三元组存储(NoSQL Triplestores)。目前正在被研究将来可能的RDF存储管理器。 三元组存储数据库最适合分类和同义词管理、链接数据集成和知识门户。

9、专用数据库

有些特殊情况需要特殊类型的专用数据库，它们的管理方式不同于传统关系型数据库。例如:

1. 计算机辅助设计和制造(CAD / CAM)。其程序和大多数嵌入式的实时应用程序一样，需要一个对象数据库。
2. 地理信息系统(GIS)。一些每年保持更新参考数据的地理空间 信息专用数据库。这些专用的GIS系统用于公用事业(电网、燃气 等)、电信管理网或航海等领域。
3. 购物车功能。在大多数在线零售网站上都有采用，利用XML数据库暂时存储客户订购数据以及用于社交媒体数据库在其他网站上进行实时广告投放。

这些数据的一部分被复制到一个或多个传统OLTP数据库或数据仓库中。另外，许多现成的供应商应用程序可能使用他们自己的专用数据 库。这些专用数据库即使它们构建在传统关系数据库之上，它们的模式也是专有的，并且大部分情况下是隐藏的。

10、常见数据库过程

数据归档

        归档（Archiving）是将数据从可立即访问的存储介质迁移到查询性 能较低的存储介质上的过程。归档后的数据可以恢复到原系统，供短期 使用。不需要活跃地支持应用程序处理的数据，应迁移到价格较低的磁 盘、磁带或CD/DVD光盘中进行归档。从归档中恢复的过程简单来说是 将归档文件中的数据复制回原系统。

归档过程必须与分区策略保持一致，以确保最佳的可用性和数据保留度。稳妥的方法包括：

1. 创建一个辅助存储区域，优先建在辅助数据库服务器上。
2. 将当前的数据库表分区成可以归档的单元。
3. 将不经常使用的数据复制到单独的数据库。
4. 创建磁带或磁盘备份。
5. 创建数据库任务，定期清理不再使用的数据。

当归档数据不同步或不一致 时，有以下几种处理方法：

1. 确定是否保留历史归档或有多少历史归档需要保留。不需要的历史归档可以清除。
2. 对于重大技术调整，在调整前将归档恢复到原始系统、升级或迁移到新系统，并在新系统下重新归档数据。
3. 对于源数据库结构发生更改的高价值归档数据，恢复归档，并对数据结构进行相应更改，用新结构重新归档。
4. 对于相对低价值的低频访问归档，在源系统的技术或结构发生改变时，保持旧系统的小版本，供有限的数据访问，并根据需要用旧系统的数据格式从归档中抽取数据。

现有技术无法恢复的归档是糟糕的归档。那些一定要用旧系统（老技术）来读取归档而其他方式无法读取归档，不管从效率或成本来看都 是不合算的。

容量和增长预测

把数据库想象成一个盒子，把数据想象成水果，把管理成本（索引 等）想象成包装材料。用隔板把盒子隔成小格子，将水果和包装材料放 进各个小格子：

1. 先确定盒子的大小。它要容纳所有的水果和必需的包装材料， 这就是容量（Capacity）。
2. 有多少水果要放进盒子，放的速度有多快？
3. 有多少水果要取出盒子，取的速度有多快？

变动数据捕获（CDC）

        变动数据捕获（Change Data Capture，CDC）是指检测到数据的变动并确保与变动相关的信息被适当记录的过程。CDC通常指的是基于日志的复制，是一种非侵入性方法，将数据更改复制到目标端而不影响源端。

数据清除

        如果所有数据都要永远保存在主要存储中，那么最终数据会填满所有的可用空间，从而使性能开始下降。此时，需要将数据存档、清除， 或者两样都要做。同样重要的是，有些数据的价值会降低，不值得继续保留。清除（Purging）是指从存储介质中彻底删除数据并让它无法恢复的过程。

数据复制

        数据复制（Replication）意味着多个存储设备上存放着相同的数据。例如，在高可用性环境中，在业务高峰期或者灾难发生时，可以在不同服务器甚至不同数据中心的相同数据库之间分配工作负载，保持业务连续性。

复制有主动复制和被动复制两种模式：

1. 主动复制（Active Replication）。不存在主副本，可以在每个副本上主动创建和存储来自其他副本的相同数据。
2. 被动复制（Passive Replication）。首先在主副本上创建和存储数据，然后把更改的状态传送到其他副本上。

数据复制有两个维度的扩展方式：

1. 水平数据扩展。拥有更多的数据副本。
2. 垂直数据扩展。将数据副本放到距离更远的不同地理位置上。

有两种主要的复制方式：镜像和日志传送（图6-7）。

1. 1）镜像（Mirroring）。作为两阶段提交过程的一个部分，在主库的更新会立即（相对而言）同步给辅助数据库。
2. 2）日志传送（Log Shipping）。辅助数据库定时接收并应用从主数据库传来的事务日志副本。

韧性与恢复

        数据库韧性（Resiliency）是衡量系统对错误条件容忍度的指标。 如果一个系统能够容忍高级别的处理错误，并且仍能像预期的那样工 作，那么它就具有很强的韧性。如果应用程序一碰到意外条件就崩溃， 那么系统就没有韧性。如果数据库可以检测异常，并提前终止或从通用的错误处理办法（如失控查询）中自动恢复，则认为它具有韧性。总有 一些意外情况，系统无法预先检测到。例如，电源故障或者被称为灾难 的情况。

这里提供了3种恢复类型，指导读者如何快速恢复：

1. 立即恢复（Immediate Recovery）。有些问题有时需要通过设计来解决的。例如，可以通过预判并自动解决问题，切换到备用系统。
2. 关键恢复（Critical Recovery）。它是指尽快恢复以尽量减少业务延迟或业务中断的恢复计划。
3. 非关键恢复（Non-critical Recovery）。它是指该类业务可以延迟恢复，直到更关键的系统恢复完毕。

数据保留

        数据保留（Retention）是指数据保持可用的时间。数据保留规划应该是物理数据库设计的一部分。数据保留需求也会影响容量规划。 数据安全性也会影响数据保留计划，出于合规考虑，某些数据需要保留到特定的时间段。未能将特定数据保留到合适的时间周期，可能会导致法律后果。同样，也有与清除数据相关的法规。如果保存时间超过 规定时间，数据可能成为一种负担。各组织应根据监管要求和风险管理 规定制定保留策略。这些策略应该有助于建立数据清除和数据归档的规范。

数据分片

        分片（Sharding）是一个把数据库中的一部分独立出来的过程。因为分片的复制只是一个很小的文件，所以分片可以独立于其他分片进行更新。因为分片通常很小，更新甚至整个分片刷新都很容易。

6.2 活动

6.2.1 管理数据库技术

管理数据库的技术应同任何其他管理技术遵循相同的原则和标准。

1、理解数据库的技术特征

        理解技术是如何工作的，以及它在特定业务环境中如何提供价值是非常重要的。DBA和数据库架构师将他们对工具的了解与业务需求结合起来，提出最佳技术应用方案，以满足组织需要。 数据专业人员必须先理解候选数据库技术的特点，然后才能确定将哪种技术推荐为解决方案。

2、评估数据库技术

选择战略性的数据库管理系统（DBMS）软件非常重要。DBMS软件对数据集成、应用程序性能和业务产能都有比较大的影响。

选择 DBMS软件时，应考虑下列一些因素：

1. 产品架构和复杂性。
2. 容量和速度限制，包括数据流传送速率。
3. 应用类别，如事务处理、商务智能、个人资料。
4. 特殊功能，如时间计算支持。
5. 硬件平台及操作系统支持。
6. 软件支持工具的可用性。
7. 性能评测，包括实时统计信息。
8. 可扩展性。
9. 软件、内存和存储需求。
10. 韧性，包括错误处理和错误报告。

还有一些因素与技术本身没有直接关系，而是与采购组织和供应商 有直接关系。例如：

1. 组织对技术风险的偏好。
2. 提供训练有素的技术专业人员。
3. 拥有成本，如软件许可费、维护费和计算资源成本。
4. 供应商声誉。
5. 供应商支持策略和版本计划。
6. 其他客户案例。

产品的费用，包括维护管理费用、许可费用和技术支持费用，不应超过产品对企业的价值。在理想情况下，技术（产品）应该尽可能方便用户、自我监控和自我管理。如果不能做到这点，那就有必要引入熟练使用相关工具的员工。 在进行全面的生产实施之前，从一个小的试点项目或者概念验证项目（POC）开始引入产品，这是一个比较好的做法，这样可以比较真实地了解成本和收益。

3、管理和监控数据库技术

        DBA通常是作为后台技术支持与服务台和供应商的支持人员一起， 理解、分析和解决用户问题。要想有效理解和使用某种技术，关键在于培训。

6.2.2 管理数据库操作

        DBA通过分配存储结构、维护物理数据库（包括物理数据模型和数据的物理分布，如分配给特定文件或磁盘区域）以及在服务器上建立数据库环境来管理各种数据存储应用程序。

1、理解需求

定义存储需求

• DBA为数据库管理系统（DBMS）应用程序建立存储系统，为 NoSQL建立文件存储系统。
• 网络存储管理员和DBA在建立文件存储系 统方面都发挥着重要作用。
• 在正常的业务运营中，数据存入存储介质， 取决于是要永久性存放还是临时性存放。在真正提供存储空间之前，做好增加额外空间的规划是很重要的。
• 所有项目都应该作第一年运营的初始容量估算，以及未来几年内的 空间增长预测。
• 数据存储需求必须考虑与数据保留相关的法规。

数据保留计划被批准后，DBA将与应用程序开发人员和其他操作人员（包括服务器和存储管理员）一起实施这些计划。

识别使用模式

可预见的几种基本的数据库使用模式，包括：

1. 基于事务型。
2. 基于大数据集的读或写型。
3. 基于时间型（月末压力大、周末压力轻等）。
4. 基于位置型（人口集中的地区有更多交易等）。
5. 基于优先级型（某些部门或者某些批处理相对有更大权限的优先级）。

定义访问需求

        数据访问包括与存储、获取或者处理存储在其他数据库和资料库中的数据等相关的活动。简单来说，数据访问就是授权访问不同数据文件的过程。

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

2、规划业务连续性

        组织需要为灾难事件、影响系统或影响使用数据的不利事件进行业务连续性规划（Plan for Business Continuity）。DBA必须确保所有数据 库和数据库服务器都有恢复计划，包括可能导致数据丢失或数据损坏的 场景，例如：

1. 物理数据库服务器失效。
2. 一块或多块磁盘存储设备失效。
3. 数据库失效，包括主要的数据库、临时的存储数据库和事务日志等。
4. 数据库索引或数据页损坏。
5. 数据库和日志段的文件系统失效。
6. 数据库或事务日志的备份文件失效。

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

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

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

备份数据

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

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

恢复数据

1. 大多数备份软件都有从备份中读取并恢复到系统的功能。
2. 文件型数据库中的数据比关系型数据库管理系统中的数据更容易恢 复。
3. 定期进行数据库的恢复测试是非常重要的。

3、创建数据库实例

DBA负责创建数据库实例。相关活动包括:

1. 安装和更新DBMS软件
2. 维护多种环境的安装，包括不同的DBMS版本
3. 安装和管理相关的数据技术

    1、物理存储环境管：

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

   确保一个完善的SCM过程需要4个步骤:配置识别、配置变更控 制、配置状态报告和配置审计。

   2、管理数据访问控制：

           DBA负责管理那些可以访问数据的控件。DBA为保护数据资产和数据完整性对以下功能进行监督: 1)受控环境。2)物理安全。3)监控。4)控制。

   3、创建存储容器

   4、应用物理数据模型

   5、加载数据

   6、管理数据复制：

           1)主动或被动复制。

           2)基于分布式数据系统的分布式并发控制。

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

4、管理数据库性能

        数据库的性能取决于两个相互依赖的因素：可用性和响应速度。性能包括确保空间的可用性、查询优化以及其他能使数据库以有效的方式返回数据的因素。

DBA和网络存储管理员通过以下步骤管 理数据库的性能:

1. 设置和优化操作系统及应用程序参数。
2. 管理数据库连接。
3. 与系统开发人员和网络管理员合作，优化操作系统、网络和事务处理中间件，以方便数据库更好地运行。
4. 提供合适的存储，让数据库与存储设备和存储管理软件有效配合。
5. 提供容量增长预测，支持存储获取和一般数据生命周期管理活动，包括保留、调优、存档、备份、清理和灾难恢复。
6. 与系统管理员一起，提供操作工作负载和基准，以支持SLA管 理、收费计算、服务器容量以及规划的生命周期轮换。

5、管理测试数据集

        测试数据是专门用于测试系统的。测试可以验证给定的输入集产生的预期输出，或者检测编程对异常、极端或意外输入的响应能力。

        根据需要，可以对生产数据进行筛选或聚合创建多个示例数据集。如果生产数据报含受保护或受限制的数据，那么样本数据必须与外界隔离。

6、管理数据迁移

6.3 工具

6.3.1 数据建模工具

6.3.2 数据库监控工具

6.3.3 数据库管理工具

6.3.4 开发支持工具

6.4 方法

6.4.1 在低阶环境中测试

6.4.2 物理命名标准

        命名的一致性有助于加快理解的速度。数据架构师、数据库开发人员和DBA可以使用命名标准来定义元数据或创建不同组织之间交换文件 的规则。

        利用ISO/IEC 11179-元数据注册表(Metadata Registries，MDR)处 理数据的语义、数据的表示和数据描述的注册。通过这些描述，可以准确地理解数据语义，并对数据进行有用的描述。

6.4.3 所有变更操作脚本化

6.5 实施指南

6.5.1 就绪评估/风险评估

就绪评估/风险评估主要围绕两个中心思想:数据丢失的风险和与 技术准备有关的风险。

(1)数据丢失

        由于技术或程序错误，或者出于恶意的目的，数据可能会丢失。组织需要制定一些制度来降低此类风险。服务水平协议(SLA)通常规定 了数据保护的一般要求，它需要得到良好的文档化程序支持。正在进行的评估需要确保强有力的技术支持，以防止恶意目的造成的数据丢失。 随着网络威胁的不断演变，建议进行SLA审计和数据审计来评估和规划风险缓解措施。

(2)技术准备

        对于新技术，如非关系型数据库(NoSQL)、大数据、三元组存储 (Triple Stores)和任务空间功能描述(FDMS)等需要IT技能和经验准备。许多组织没有掌握集成这些新技术优势所需的技能。DBA、系统工程师和应用程序开发人员以及商业用户必须做好发挥这些技术在商务智能及其他应用领域作用的准备。

6.5.2 组织和文化变化

        DBA往往不能有效地提升自身工作对组织的价值。他们需要认识到数据所有者和消费者的合理需求，平衡短期和长期的数据需求，在组织中将数据管理实践的重要性灌输给他人，优化数据开发实践，以确保使组织利益最大化和对数据消费者的影响最小化。

1. 主动沟通。DBA在开发期间和开发完成后，都应与项目团队密切沟通，尽早发现并解决问题。他们应该审查开发团队编写的数据访问代码、存储程序、视图和数据库函数，并帮助解决数据库设计中的问题。
2. 站在对方的立场上与之沟通。例如，同业务人员交流业务需求和投资回报会更好一些，与开发人员讨论面向对象、松耦合和开发的易用性更合适一些。
3. 保持专注于业务。应用程序开发的目标是满足业务需求并从项目中获得最大的价值。
4. 对他人要有帮助。总是对他人说“不”会导致对方忽略标准，另谋他路。需要让对方认识到，虽然每个人都需要完成自己分内的工作， 但是在他人成功的道路上不施以援手对彼此都不利。
5. 不断学习。评估在项目实施中遇到的挫折，吸取教训，以规避再次出现类似的问题。

6.6 数据存储和操作治理

6.6.1 度量指标

数据存储的度量指标，包括:

1. 数据库类型的数量。
2. 汇总交易统计。
3. 容量指标。
4. 已使用存储的数量。
5. 存储容器的数量。
6. 数据对象中已提交和未提交块或页的数量。
7. 数据队列。
8. 存储服务使用情况。
9. 对存储服务提出的请求数量。
10. 对使用服务的应用程序性能的改进。

性能度量评估指标，包括:

1. 事务频率和数量。
2. 查询性能。
3. API服务性能。

操作度量指标，包括:

1. 有关数据检索时间的汇总统计。
2. 备份的大小。
3. 数据质量评估。
4. 可用性。

服务度量指标，包括:

1. 按类型的问题提交、解决和升级数量。
2. 问题解决时间。

DBA应与数据架构师和数据质量团队一起讨论度量指标的需求。

6.6.2 信息资产跟踪

        数据存储治理中的一部分是确保数据库遵守所有许可协议和监管要求。因此，应该对软件使用许可、年度支持费用以及服务器租赁协议和其他固定费用，进行仔细跟踪和年度审计。不遵守许可协议会给组织带来严重的财务和法律风险。

        审计数据可以帮助确定每种技术和产品的总拥有成本(TCO)。定期评估那些过时、过保、用处不大或太昂贵的技术和产品。

6.6.3 数据审计与数据有效性

        数据审计是根据定义的标准对数据集进行评估的过程，通常是对数据集的特定关注点进行审计。审计的目的是为了确定数据的存储是否符合合同和方法要求。数据审计方法可能包括一个项目特定和全面的检查表、所需的可交付成果和质量控制标准。

        数据验证是根据既定的验收标准评估存储数据的过程，以确定其质量和可用性。数据验证程序依赖于数据质量团队（如果该团队存在）或其他数据使用者的需求所建立的标准。DBA对数据审计和验证提供部分支持工作，包括:

1. 帮助制定和审查方法。
2. 进行初步的数据筛选和审查。
3. 开发数据监控方法。
4. 应用统计信息、地理统计信息、生物统计信息等技术来优化数据分析。
5. 支持采样及分析。
6. 审核数据。
7. 提供数据发现的支持。
8. 担任与数据库管理相关问题的主题专家。