数据库管理成熟度模型

  

  

  

  

  

  

数据库管理成熟度模型

Ver 1.1

 作者: Thomas B. Cox

翻译: 崔晓波(local0)

目录

 ¨         数据库管理成熟度模型

 ¨         数据管理员、数据库管理员和数据设计者的区别

 ¨         任务性质的区别

 ¨         数据库生命周期

 ¨         数据库设计者和数据库管理员

 ¨         数据库生命周期中的任务

 ¨         数据库生命周期和DBA的任务

 ¨         DBA任务流程（对于成熟数据库）

 ¨         SLA协议样本

一、        数据库管理成熟度模型

DBA MM：Database Administration Maturity Model

本文档讨论了数据库管理，勾画出ORACLE数据库管理员在开发阶段和维护产品

阶段应该执行的任务。

DBA MM分为5个级别

级别

焦点

关键处理域

初步（INITIAL）

关注：没有

工具：个人发挥（HEROISM）

u       成功是偶尔发生的和不可重复的

u       工作表现为：紧急应对、救火、个人发挥

可重复（REPEATABLE）

关注：可重复的DBA过程

工具：DBA 日常检查列表

u       项目计划（DBA项目、DBA开发支持）

u       项目跟踪、勘漏（DBA项目）

u       子项目管理（DBA项目外包或子项目）

u       配置管理（数据库软件、DBA工具、变更管理）

定义（DEFINED）

关注：将DBA处理工作定义化、文档化

工具：DBA培训

u       需求管理（服务级别）

u       质量保证（DBA任务）

u       最佳的实践被明确化并可传播（培训）

u       工作被明确定义，任务执行情况可以被确切的度量

管理（MANAGED）

关注：过程控制，即DBA处理流程是稳定的和可度量的，所有的变化及其起因都被记录和标注。

工具：SLA

u       所有变化都能可控的记录下来，并在变化的之前和之后进行度量，以确认变化是否有效。

优化（OPTIMIZING）

连续的过程优化：

首先要可重复才能提高

首先要可定义才能度量

首先要可度量才能管理

u       管理实践中得到提高，技巧得到提炼

u       变化的因素得到系统的控制，教训学习中得到更大的提高

二、        数据管理员、数据库管理员和数据设计者的区别

根据数据库使用过程中任务的不同，划分为3个任务集合：

（1）       数据管理任务

（2）       数据设计任务

（3）       数据库管理任务

可能会一人同时担当多个角色，但是3类角色的任务是不同的，表现在：一方面任务的性质是不一样的，另外一方面，不同的任务出现在数据库生命周期的不同阶段。

 三、        任务性质的区别

 1、数据设计  

   数据设计关注数据的逻辑、物理模型的建立，这些模型之后会作为对象存储在数据库中。

   为解决特定的商业问题，在应用所涉及的范围中，建立这些模型，顺序是：

   应用范围 à 商业需求 à 数据逻辑模型 à 数据物理模型

   数据设计负责以下具体方面：

u       建立的模型能够充分满足商业问题的需要。

u       确保模型在构建在应用领域之内（通常模型涵盖的范围略大于应用所需，这是为了将来应用系统与其他系统接口，但是模型不能过大的脱离实际应用）

u       建立一个用户可以接受的物理模型（影响性能提高的主要因素是应用的编码，数据设计者应该尽可能的提高性能，而不是破坏它）

2、数据管理

   数据管理负责制定访问策略：谁拥有什么数据、谁能创建、改变、删除什么数据，

   数据管理者必须跟踪控制数据元素的所有权，这项工作与数据的设计无关，也和数据的

存放细节（DBA）无关。具体而言：

u       谁拥有数据

u       谁拥有数据的定义

u       在数据的生存周期中，如果需要变更所有权，什么时候、如何改变（如销售人员拥有定单一直到定单提交，发货人员接着拥有它一直到货物发出，然后由财务人员拥有，直到受到货款）

 3、数据库管理

 3、数据库管理

   数据库管理员负责维护数据库的物理运行（如将数据存放在某个磁盘上），DBA负责：

u       维护数据库，使它运行在数据库开发者要求的状态下。

u       进行调优、分担负载、打PATCH、升级、备份、恢复等

u       除了逻辑访问（应用级）以外的数据库所有方面。 

    特别注意，DBA的职责中没有写SQL应用，写SQL应用是开发者的工作，如果DBA承担这项任务，他就成

为开发人员，不是DBA。

  四、        数据库生命周期

一个新的数据库诞生，通常是为了满足新的应用（或需要在老的数据库上无法做大量的改变），为合理的构建数据库，必须有人分析应用，设计合适的表结构（使用E-R模型，而后影射为数据表，也可以直接设计数据表）。设计表应先于其他的阶段。

设计表主要由数据设计者完成，除了设计表之外，数据设计人员还负责影响分析，这发生在应用需求变化时，决定需要进行哪些变更。

数据库生命周期

设计者

数据管理者

DBA

1．决策、分析

表设计，安全设计

数据所有权，安全策略

 

 

 

 

 

 

 

 

 

数据库生命周期

设计者

数据管理者

DBA

2．设计，建造

影响分析

变更管理

安装，生成数据文件，表、表空间建立，备份/恢复计划，安全过程

3．幼年

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

物理重组，性能调优

4．成熟

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

异常情况监控，性能监测，性能调优，执行备份/恢复，数据文件管理

A．小变更

影响分析

变更管理

表修改

 

 

 

 

 

 

 

 

 

B．大变更

影响分析，表重设计

变更管理

建表

每当应用的需求发生变化时，数据管理员都需要进行变更管理，以确保所有的数据属于相应的用户。

         在项目的后期，表的设计完成后，开始由DBA进行建表，包括空间划分，存储参数设置（根据数据设计人员的要求），分布数据以获得负载平衡。如果遵从OFA（OPTIMAL FLEXIBLE ARCHITECTURE）DBA必须按照OFA的要求进行数据文件划分。

 五、        数据库设计者和数据库管理员

   区分数据设计者和DBA，关键的一点不同是：

Ø         数据设计人员的工作在于数据库的逻辑构建（实体、关系、表设计）

Ø         数据库管理员的工作在于物理问题的解决（数据文件、磁盘负载分担、备份、恢复）

        这种观点有其正确性，但是如果严格按照这种分法，也存在潜在的问题。让数据设计人员有数据库物理构建方面的知识，是一种很好的方法，这使数据的设计可以方便的实现和维护。在汽车制造行业，类似的行为称为“为制造而设计”。设想设计人员面临两个选择，它们在功能上完全一样，但其一的制造很廉价，如果设计者没有生产方面的知识，他将不知道哪个方案更廉价、更容易实现。

       另外曲解这一观点的做法是：让DBA负责数据库设计。有些人的确这样做，他们通常进行设计仅仅考虑如何易于维护，而忽略了应用的要求，这样的设计通常以失败告终。

以下是根据任务的不同，列出数据库生命周期的任务分布：

执行者

任务

频率

生命周期的阶段

描述

设计者

表设计

一次

1 ， B

设计符合应用要求的表结构，当需求改变时，做相应的调整

执行者

任务

频率

生命周期

描述

设计者

安全设计

一次

1

确保数据库的设计满足应用的安全性要求

 

 

 

 

 

 

 

 

 

影响分析

根据需要

2，A，B

当应用改变时，审视数据库设计的那些方面需要相应的调整。

数据管理者

数据所有权

一次

1

确认谁拥有哪些数据，并对之进行维护。

 

 

 

 

 

 

 

 

 

安全策略

一次

1

决定谁可以授权访问数据，谁可以在什么时候将那些数据共享给别人

 

 

 

 

 

 

 

 

 

变更管理

根据需要

2，A，B

当应用或其数据发生变化时，确保所有数据保持清晰的所有关系，通知相关需要改变的用户

DBA

安装

一次

2

安装数据库

 

 

 

 

 

 

 

 

 

创建数据文件

一次

2

为特定的表空间创建数据文件，减少磁盘访问冲突，根据设计使用OFA。

 

 

 

 

 

 

 

 

 

制定备份/恢复方案

一次

2

建立备份恢复方案，并进行测试

 

 

 

 

 

 

 

 

 

安全措施

一次

2

创建role,分配数据访问权限，系统权限，创建用户，初始化审计功能。

 

 

 

 

 

 

 

 

 

表-表空间映射

一次

2

根据OFA或其他的准则，创建表-表空间对应关系，并向使用文档纪录

 

 

 

 

 

 

 

 

 

创建表

一次

2，B

在相应的表空间上创建表

 

 

 

 

 

 

 

 

 

物理重构

根据需要

3

在表空间内重构表，创建/改变索引，创建/改变簇，

 

 

 

 

 

 

 

 

 

性能调优

根据需要

3，4

起初查找物理配置的严重问题，如索引没有建等。当数据库建成后，通过性能监测任务，对需要调整的部分进行调优。

 

 

 

 

 

 

 

 

 

异常监测

每天

2，3，4

通过LOG，TRACE等日志检查异常情况，通过EMAIL接受用户的问题报告。

 

 

 

 

 

 

 

 

 

性能监测

每周

4

根据事前定义的SLA等，对数据库的性能进行检查。

 

 

 

 

 

 

 

 

 

数据文件管理

根据需要

4

根据需要分布数据文件，扩展数据表空间

 

 

 

 

 

 

 

 

 

执行者

任务

频率

生命周期

描述

DBA

执行备份/恢复

每天

4

执行在线、离线、日志等备份，需要时进行恢复。

 

 

 

 

 

 

 

 

 

表修改

根据需要

A

当应用发生小的改动需要变动表时，DBA必须在保证已有数据可靠性前提下进行修改。

 六、    数据库生命周期中的任务

    1、安装

   2、创建数据文件

3、制定备份/恢复计划

备份/恢复是保证数据库可用性的重要手段，要尽可能的将以外的中断降低的最小。

步骤：

u       建立数据库的备份恢复策略

u       形成备份恢复文档

u       测试备份恢复

u       由其他专家进行审查

u       使备份/恢复策略符合SLA

u       如果资源不能达到SLA的要求，逐步升级。

   4、安全策略

关于数据库安全性有三个级别：

UNIX用户名/口令认证

ORACLE用户名/口令认证

与应用相关的安全特性

网络的认证与数据库没有直接的关联，但是它也构成了一个安全级。

步骤：

u       决定使用哪个级别的安全控制

u       部署相应的安全机制

u       根据需要管理用户、角色

u       检查安全机制

5、表-表空间对应

6、建表

7、物理元素重组

包含以下：

u       将一个表由一个表空间搬移到另一个

u       创建所需的索引

u       创建集簇

u       定义水平分割

u       压缩表的extents，通过backup/exp/drop/imp

u       压缩索引的extent，通过 drop/re-create

                   ORACLE物理存储的几个概念：

Ø         Data blocks

最小的存储粒度，所有的ORACLE数据以BLOCK为单位存储和分配空间（又称逻辑块、ORACLE块、页）。一个数据块对应着一定BYTES的磁盘空间，当数据库创建时即指定了数据块大小。

相比较，操作系统的块仅仅是一定数量的BYTES集合，数据的物理存储以BYTE为单位。

Ø         Extents

EXTENT是一定连续的BLOCK的集合，用于分配存储一个特定的信息。

Ø         Segments

逻辑上EXTENT之上是SEGMENT，SEGMENT是一个EXTENT的集合，用于给一个特定的结构分配空间，SEGMENT限制在一个表空间中。

8、性能调优

性能调整是一个长期的过程，正确的调优可以带来很大的好处，但是不恰当的调优可能会带来负面的影响，随意的调整可能带来不可预知的后果。

通常调优必须在一定的约定范围内进行，并遵循预先设置的准则，这样才能保证性能可以被度量、可信赖和精确。

在如下的情况下才进行数据库调优：

（1）有适当的SLA

（2）有可信赖的性能度量指标

（3）数据库没有达到SLA的性能要求

有两种可以接受的调优结果：

   （1）数据库的性能达到了SLA的要求

   （2）调优的不可行或不可能，SLA的标准经过协商接受目前的性能

9、异常情况监测

异常监测是DBA最重要的例行工作，它可以使DBA预先发现问题的前兆。

DBA至少需要监测：

（1）       用户反映的异常情况，出错信息等（DBA应该详细记录下来）

（2）       在alert、trace等日志中的异常记录

10、性能监测

这项工作使DBA感受数据库发生问题的耳目，至少需要做：

（1）每个表空间空闲内存的碎片情况

（2）每个表空间的空闲空间

（3）       数据库的增长率

（4）       测算出数据库目前资源什么时候会耗尽

（5）       每个表、索引超过门限的extent数量

（6）       对查询或事务（insert,update,delete）的响应时间

（7）       alert,trace日志中异常的记录

11、数据文件管理

12、执行备份/恢复

13、表的修改

七、    数据库生命周期和DBA的任务

        什么时候做什么任务，前提是数据库已经处于“成熟时期”

1、 性能监测

性能监测必须依照SLA并经常由用户进行反馈，根据经验，当系统刚刚建成时，需要

每天监测，当系统已经稳定，每周监测一次。

（1）每个表空间空闲空间的碎片情况

如果出现蜂巢状碎片，则使用粘和工具（ORACLE7以后版本自动进行coalescing工作）；如果空洞的碎片太大，空闲空间较小，则忽略空洞，在建立一个数据文件；如果此时磁盘空间过小，则进行backup/exp/drop/imp来重新整理。

（2）每个表空间的剩余空间

（3）计算表空间空闲率

注意TEMP不在关注之内，确认ROLLBACK使用了OPTIMAL存储参数。

（4）关注什么时候空间会耗尽

（5）关注大于4个EXTENT的对象

定期压缩EXTENT，如果某个对象的EXTENT总被压缩，应考虑增加其NEXT EXTENT大小，如果某个对象达到了最大的EXTENT数，应立即增加NEXT和压缩。

（6）检查测试查询、修改例程的响应时间

构建例程是SLA的一部分，一旦SLA协商确定下来，定期运行以衡量数据库的运行情况，如果出现问题时例程没有表现出来，则更换例程。

（7）根据SLA记录响应时间

（8）每天检查相关的日志文件

（9）记录下发现的问题或异常现象

   2、制定备份/恢复计划

   （1）根据SLA制定备份计划，并生成文档

   （2）由其他专家进行确认

   （3）针对主要的数据库发生问题的情况，制定恢复方案，并生成文档

   （4）在测试ORACLE INSTANCE上进行恢复计划测试

   （5）如果SLA的某个要求达不到，或者改进方案或修改SLA

   3、执行备份/恢复

详细记录下所有的操作步骤和时间。

   4、Service Level Agreement

（1） SLA应该就数据库服务的以下方面划分出级别

Ø         列出停机时间表 ：hours/day , days/week , days/year

Ø         处理典型查询、事务的响应时间

Ø         在崩溃情况下，最长的恢复时间和最大的数据损失情况

（2）SLA的细节将在DBA的任务中体现如

Ø         “每年的最大停机时间”à DBA监测数据库的频率

Ø         “最大数据损失” à log文件的大小，CKPT的间隔

八、    DBA任务流程（对于成熟数据库）

九、SLA协议样本

  Service Level Agreement

服务

级别定义

系统运行时间

24小时

系统可用时间

24小时/天 ， 7天/周

热备份频率

每天，增量备份archive log

冷备份频率

每年4次

每次崩溃最大数据损失

不大于一天的数据

从软崩溃（如断电）启动时间

电源正常后15分钟内

从硬崩溃（如磁盘失效，但是不丢失数据）启动时间

更换硬件1小时，启动15分钟内完成

从硬崩溃（如磁盘失效，损坏数据）启动时间

1小时更换硬件，15分钟启动数据库，3小时从备份恢复

每年宕机时间

12天/年，一天/月，每月的第二个周六

BUG报告响应时间

协商

增强功能响应时间

协商

新应用需求响应时间

协商

查询响应时间

协商（需要制定指标测试程序）

每年总计计划停机时间

12小时

计划停机时间

劳动节、感恩节、圣诞节、新年，每次3小时

每年机动停机时间

4小时/年