数据库管理成熟度模型
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小时/年 |