数据操作管理

一、简介

　　数据操作管理是结构化数据的开发、维护和支持的活动,使企业数据资源达到最佳的利用价值。数据操作管理包括两项子职能:数据库支持和数据技术管理。

　　数据操作管理的目标是:

　　　　(1)保护和确保结构化数据资产的完整性。

　　　　(2）管理数据在其生命周期内的可用性。

　　　　(3）优化数据库事务性能。

　　数据操作管理内容如图6.1所示。

二、概念和活动

　　在第一章提到数据操作管理是提供从数据获取到数据清除整个过程的支持功能。数据管理员(DBA)起着极其重要的作用。本章将阐述数据操作管理的概念﹑相关活动以及数据库管理员在这些活动中所承担的角色。

2.1 数据库支持

　　数据库支持是数据管理的核心,此任务由DBA完成。DBA角色是历史最悠久和最广泛被采用数据专业角色。在所有数据管理实践中数据库管理也许是最成熟的实践。DBA在数据操作管理(参见第6章)及数据安全管理(参见第7章)过程中起着主导作用。第5章中已谈到,DBA也在数据开发职能中发挥关键作用,尤其是在物理数据建模和数据库设计阶段,以及支持开发和测试数据库环境方面。

　　事实上,许多DBA 被区分为开发DBA或产品DBA。开发DBA着重于开发活动,而产品DBA着重于实施数据操作管理活动。在某些企业,两种 DBA分别报告给IT部门的不同团队。产品 DBA也许是生产基础设施和操作支持组的组成部分。开发 DBA和产品DBA有时被整合到应用开发组。

　　产品 DBA 在数据管理中的主要责任如下:

　　　　• 确保数据库性能和可靠性,包括性能调优,监控及错误信息报告。

　　　　• 对数据库实施恰当的备份和恢复机制,以保证任何场合下数据的可恢复性。

　　　　• 实施集群和数据库故障转移机制以实现数据持续可用性的需要。

　　　　• 实施对数据的归档操作管理机制。

　　产品 DBA主要负责提交以下项目:

　　　　(1)创建产品数据库环境,包括 DBMS实例以及相应服务器,提供充足的空间容量以保障合适的运转性能;配置适当的安全级别、可用性级别和可靠性级别。数据库系统管理负责 DBMS的环境。

　　　　(2）对数据库生产环境的实施和变更提供可控制的机制和流程。

　　　　(3）提供恰当的保护机制确保数据的可用性、完整性和可恢复性,以应对任何有可能导致数据丢失或损坏的情况。

　　　　(4）恰当的数据库检测及报告机制,包括DBMS或数据服务器上出现错误信息的机制。

　　　　(5)服务水平协议所定义的数据库可用性、可恢复性和运转性能。

　　不是所有数据操作管理活动都由DBA独自承担。数据管理专员、数据架构师、数据分析师也参与规划数据恢复、保留和性能方面活动,除此以外,他们还参与获得和处理外来数据的过程。

2.1.1 实施并控制数据库环境

　　数据库系统的管理包括下列任务:

　　　　• 更新 DBMS软件——DBA负责安装新版本 DBMS 软件,负责实施各种数据库环境下由厂商提供的各种维护和修复,包括开发环境到产品环境。

　　　　• 维护多项不同版本的DBMS 安装一—DBA 安装维护若干项不同环境下的 DBMS软件,包括开发环境、测试环境及产品环境,同时还负责管理DBMS版本在各个环境之间的合理迁移。

　　　　• 安装和管理相关数据技术工具,例如数据整合软件以及第三方数据管理软件等。

　　　　• 设置和调试 DBMS 系统参数。

　　　　• 管理数据库的连通性——除数据安全问题(参见第7章)以外,企业范围内访问数据库需要用户具备一定的专业知识。DBA对需要连接数据库的IT用户和业务用户，为之提供技术指导和支持服务。

　　　　• 与系统程序员,网络管理员合作共同调整与 DBMS相协作的操作系统,网络和事务处理中间层的性能。

　　　　• 为DBMS划分适当的存储空间,使 DBMS能使用外部存储设备和存储管理软件。存储管理优化利用不简存储技术存储不同种类数据。存储管理软件会将不经常被引用的数据转移到廉价的存储器上,这个做法导致的直接后果是重复访问此类数据会耗时较长。有些数据库能与存储管理软件结合,从而将分区表中的过时数据转移到较慢,但便宜的存储器上。DBA和存储管理员合作制定并监护有效的存储管理步骤。

　　准备一份工作清单以确保高质量地完成上述任务,清单中应列出详细步骤。任何 DBA修改工作都应在其他 DBA 评审之后方能进人产品环境。

　　DBA是所有数据库修改的监管人。其他人员只能提出修改请求,由 DBA定义准确的修改方案,并实施和控制更改。DBA 应使用可控制的,有完整备案的和可评审方案步骤,将应用程序的数据库修改实施到质控环境和产品环境中去,而这个要求的部分原因是萨班斯法案以及其他相关法规条例要求。通常此过程是以经理批准一项服务请求或变更请求为出发启动。在大多数情况下 DBA应该预备回退方案以应付问题的发生。

　　所有更改都必须首先在开发环境/测试环境进行QA检验,最后在产品环境下测试所有变更,而在QA环境紧急变更时除外。开发 DBA 控制开发和测试环境,产品 DBA 控制产品环境和QA环境。

2.1.2 获取来自外部的数据

　　大多数企业都要获取部分外源数据,例如从信息经纪人那里购买潜在客户名单,或由供应商提供的有关产品数据。这些数据可能是许可的,也可能是免费提供的,它们以不同的格式(CD、DVD、EDI,XML,RSS feed,文本文件)一次性,或通过订阅服务定期更新,有时需要签订一些法律协议。

　　数据采集的管理办法是把数据订阅服务的职责集中在数据分析人员身上。数据分析师应把外部数据源记录在逻辑数据模型和数据辞典内;开发人员可据此设计并编写相关的将外部数据读取和加载到数据库中的程序;DBA负责实施必要的过程将数据加载到数据库中,供其他应用程序使用。

2.1.3 规划数据恢复

　　数据治理委员会应与IT数据管理部门建立数据可用性及恢复的服务水平协议(SLA)。服务水平协议设定数据可用性期望,允许的数据库维护和备份时间,设定不同场景下的数据恢复期望时间,包括潜在的灾难事件等。

 　　DBA必须保证制定所有数据库、数据库服务器恢复计划,并要涵盖所有导致数据丢失、损坏的可能场景,包括如下但不限于此的可能事件:

　　　　• 物理数据库服务器损失。

　　　　• 一个或多个存储器损失。

　　　　• 数据库损失,包括 DBMS主数据库、临时存储数据库、事务日志段等。

　　　　• 数据库索引、数据分页损坏。

　　　　• 数据库或日志段文件系统损坏。

　　　　• 数据库或事务日志备份文件损坏。

　　管理层和组织的业务连续性管理部门(如果存在的话)应该评审并批准数据恢复规划。所有数据恢复计划应易于被所有DBA人员访问。DBA备份所有恢复计划联同所有相关软件,以及有关安装、DBMS配置说明、安全码,例如管理员密码,应存放于现场以外的安全地方,以备灾难发生时应用,同样所有数据库备份也应存放于现场以外的安全地方。

2.1.4 备份和恢复数据

　　DBA应定期备份数据库,OLTP 数据库和数据库事务日志。数据库服务水平协议中应该包含数据拥有者对数据备份频率的协议。DBA需要对数据的重要性和保护数据所需付出的代价之间作出权衡。大数据库的频繁备份会消耗大量磁盘存储和服务器资源。最低限度,每个数据库每日进行一次完全备份。

　　此外,数据库应存放于某些有管制的存储区,理想的是在存储区域网络的RAID阵列或SAN上,每天会把数据备份到磁带上去。对OLTP数据库,其事务日志的备份频率取决于数据更新频率和涉及的数据量。对更新率较高的数据库,频繁地将日志区数据转储不仅能提供更好的保护,还能减少备份对服务器资源应用程序所带来的影响和冲击。备份文件应存储在与数据库分离的文件系统中,并每天将备份文件转到磁带上,或一些分离存储介质上。将每日备份文件存储到现场以外的安全设施上。

　　对极其重要数据,DBA需要实施一些复制方案将数据转移到远程服务器的其他数据库。万一发生数据库事故,应用程序能故障切换到远程数据库继续运行。有几种不同的复制方案,包括镜像和日志传送。在镜像方案中,主数据库的更新被立即复制(相对而言)到辅助数据库,类似两阶段提交过程。在日志传送方案中,辅助服务器定时接收并载人主数据库的事务日志副本。复制方案的选取取决于数据的重要性和立即故障切换到辅助服务器的重要性。镜像方案通常比日志传送方案要昂贵得多。针对一个辅助服务器用镜像方案;其余辅助服务器的更新用日志传送方案。

　　其他数据保护选项比如服务器集群,这种方法在使用共享磁盘阵列的多个数据库实例在发生个别实例出现故障情况下,可以从故障的数据库实例换到正常运行的数据库实例;服务器虚拟化,故障切换可以发生在位于两个或多个物理主机上的不同虚拟服务器之间。

　　大多数DBMS支持热备份——即在应用程序正常运行的过程中执行备份。当热备数据传送过程发生了更新,DBMS 要么向前滚动完成事务,要么在备份重新加载的时候回滚事务。另外的可选方案是冷备份,备份发生在数据库离线的时候。如果你的应用要求连续可用性,则冷备份机制不合适。

　　必要时 DBA也负责通过重新加载必要的数据库和事务日志备份最大可能地恢复丢失的数据或被损坏的数据。

2.1.5 设定数据库性能服务水平

　　可从以下两个方面评价数据库:可用性及性能。性能是以可用性为前提的。没有可用性的性能将没有意义;换言之，一个不可用的数据库其性能度量等于零。

　　数据服务管理部门与数据所有人之间通过服务水平协议定义对数据库的性能期望。一般来说,协议中规定了数据库可用性时间和有选择的几个应用程序事务(复杂查询和更新的组合),在确定的可用性时期指定最大允许执行时间。如果处理的执行时间连续超出协议中所规定的时间,或数据库的连续可用性不能满足协议要求,数据所有人有权要求DBA 查找问题原因并提供适当的补救措施。

　　可用性是系统或数据库能提供正常生产工作的时间百分比。不断提高可用性需求会增加业务风险以及数据不可用导致的损失。确保可用性的活动越来越多地安排在日益收缩的维护时间窗口中。

　　如下4项因素影响数据库的可用性。

　　　　• 可管理性———产生可维护有效环境的能力。

　　　　• 可恢复性—发生中断时重建服务的能力,改正不可预料事件/失败组件所导致错误的能力。

　　　　• 可靠性——在所规定时期内可提供指定服务水平的能力。

　　　　• 可服务性—确定问题所在、诊断错误原因以及修复和解决问题的能力。

　　许多方面的因素可以导致丧失数据库可用性,列举如下:

　　　　• 预期和非预期停机。

　　　　• 服务器硬件损失。

　　　　• 磁盘硬件失效。

　　　　• 操作系统失效。

　　　　• DBMS 软件失效。

　　　　• 应用程序问题。

　　　　• 网络失效。

　　　　• 数据中心损失。

　　　　• 安全和授权问题。

　　　　• 数据损坏(由于软件设计不良、用户错误所致的)。

　　　　• 数据库对象丢失。

　　　　• 数据丢失。

　　　　• 数据复制失败。

　　　　• 严重的性能问题。

　　　　• 恢复失败。

　　　　• 人为错误。

　　DBA有责任采取各种措施保证数据库在线运转正常,其中包括:

　　　　• 运行数据库备份程序。

　　　　• 运行数据库重组程序。

　　　　• 运行各类统计程序。

　　　　• 运行完整性检查程序。

　　　　• 所有程序运行自动化。

　　　　• 利用表空间的聚集和分区。

　　　　• 通过镜像数据库复制数据以确保高可用性。

2.1.6 监控并调整数据库性能

　　通过监控数据库性能和迅速的对问题做出反应,DBA可以主动或被动地优化数据库。大多数DBMS 提供性能监护功能,使DBA生成分析报告。大多数服务器操作系统也提供相似的监控和报告功能。即使在很繁重的活动下, DBA 也应该定期执行针对DBMS 和服务器的各种性能检测活动并生成相关报告。DBA应该保存这些报告,对新旧报告进行比较分析以发现消极的趋势,这样做也有助于分析那些伴随时间推移产生的问题。

　　随着在线交易通常实时的发生数据移动的情况。然而许多数据移动和转换活动是通过批处理程序完成的,这通常是一些ETL(提取-转换-加载)程序,或者只限于系统内运行的一些程序。批量工作必须在特定的时间窗口内有计划地完成。DBA同数据整合专家共同监控批处理作业的性能,发现异常次数和错误,定位根本原因并解决所有问题。

　　当性能问题出现时，DBA应该利用DBMS 的监护和管理工具来协助确定问题原因。下面是一些常见的可能导致数据库性能低下的原因。

　　　　• 内存分配(数据的缓冲区/高速缓存)。

　　　　• 锁和阻塞——在某些情况下,数据库内的运行进程可能会锁住数据库资源,例如,表和数据页,这样会导致阻塞需要相同资源的其他进程。如果问题持续太长的时间间隔, DBA可以终止阻塞的进程。在另外一些情况下,两个进程需要彼此之间的资源引起“死锁”。大多数DBMS在发生死锁事件后会自动终止其中一个进程。这种状况通常是数据库或应用程序糟糕的编码所引起的。

　　　　• 更新数据库统计失败-—大多数关系 DBMS系统都有内置的查询优化器,它们依靠有关的数据和索引统计数字决定一个查询的最有效执行方式。定期和频繁地更新这些统计结果,特别对那些活跃的数据库是很重要的。不这样做的结果是如果没做好,可能会导致更低效的查询。

　　　　• SQL编码不良——SQL编码不良也许是导致低效能数据库的最常见原因。查询编程员要对SQL查询优化器有基本了解,所编写SQL应该充分利用优化器的效能。把复杂的SQI语句封装在存储过程内,这样可以做到预编译和预优化,而不是嵌入在应用程序代码中。利用视图预定义复杂的表链接。另外,避免在数据库函数中用表链接以及复杂SQL,因为这不像存储过程,这样会导致查询优化器对其难以理解。·索引欠缺——-编辑复杂的查询,查询涉及大表格时,要利用表内索引。创建必要的索引以支持这些查询。同时注意不要在更新频繁的表格中生成过多的索引,索引过多会引起更新处理减慢。

　　　　• 应用程序活动——理想的状态是不要把应用程序同DBMS安装在同一个服务器上,否则它们会竞争服务器资源。为最大性能目标去配置和调整数据库服务器。另外,新型 DBMS 允许应用程序对象,例如Java和.NET类可封装在数据库对象中并在 DBMS上执行,但要小心谨慎利用这些功能。在某些情况下,这种特性非常有用,但在数据库服务器上执行应用程序会影响数据库运行效能。

　　　　• 数据库的数量,规模或者使用的上升—如果 DBMS支持多个数据库,支持多个应用程序,持续增加数据库可能会出现性能转折点,如果此时再添加数据库﹐就会使现有的数据库性能下降。在这种情况下,应该创建新的数据库服务器。此外,对增长很大的数据库,或在使用上比以前大大提高的数据库,应该重新安置其到新的服务器上。在某些情形下,解决问题只需通过归档使用频率较少的数据,或删除过期的/废弃的数据。

　　　　• 数据库波动——在某些情况下,短时间内进行大量的表插入,删除会导致数据库分布统计信息不准确。这时需要关闭数据库对这些表格的统计更新,因为这些不准确的统计数据能导致对查询优化器的不良影响。

　　　　• 在鉴定出问题原因之后,DBA要采取一切可能的行动解决问题。这其中包括与应用程序开发员一起提高优化数据库代码,归档或删除不再被应用程序所用的数据。

　　在个别例外的情况下,DBA可以考虑同数据建模人员一起对受影响的部分数据库进行反范式化。这种行动只有在实施其他行动无效后方可应用,例如,前面所提及的:生成视图,增加索引,重写SQL编码,还要仔细考虑各种可能导致的后果,像数据完整性丢失,以及反范式化所增加的SQL复杂性。这种警告只适用于OLTP数据库,而对于只读报告和分析型的数据库来说,反范式化所带来性能和访问的便捷性好处要远大于产生的意外,基本不构成什么威胁或危险。

2.1.7 规划数据留存方案

　　物理数据库设计的最重要部分之一是数据留存规划。在数据库的设计期间与数据所有者讨论数据保留问题,并达成如何在数据有效期内使用数据的协议。不要以为所有数据会永远驻留主存储器上。不再有效支持应用程序处理的数据应该归档并转移到次存储器上﹐次存储器由较廉价的磁盘,磁带或CD/DVD介质柜组成,也可能在不同的服务器上。清除废弃的、没用的数据,即使出于监管目的的数据也需如此。有些数据如果保留超过所需时间反而会成为-一种责任。切记数据管理的主要原则之一是维护数据的代价永远不应该超过这些数据带给公司的价值。

2.1.8 归档,留存和清除数据

　　DBA应该同应用开发人员以及其他操作员,包括服务器管理员、存储管理员合作实施已经批准的数据留存规划。这可能需要以下程序:生成副存储区,建立副数据库服务器,复制不用或少用的数据到不同的数据库上,对现有的数据表分区,安排磁带或磁盘备份,生成数据库作业周期性来清理无用数据等。

2.1.9 支持专用数据库

　　不要认为单一类型的数据库架构或DBMS会满足所有需要。特殊的情况下需要特殊类型的数据库,而这些专用的数据库在管理上与传统关系型数据库有所分别。例如,大部分计算机辅助设计和计算机辅助制造(CAD/CAM)应用程序需要对象数据库,它们往往也是嵌人式实时应用程序。地理空间应用,如 MapQuest利用专用的地理空间数据库。其他应用程序,见于大多数在线零售网站的购物车程序,利用XML 数据库预先存储客户订购数据,然后再将数据复制到一个或多个传统OLTP数据库或数据仓库中。除此之外,许多现成的供应商应用程序可能使用自己的专有数据库。至少,其数据库模式是专有的,保密的，即使它们实际存在于传统关系 DBMS 之上。

　　仅仅用于支持一个特定应用程序的数据库不难管理。DBA主要负责确保定期备份数据库,执行数据库恢复测试。然而,如果要将这个数据库上的数据融合到其他一个或多个关系数据库中的数据上去时,数据整合是一个严峻的挑战。这些问题应该在向公司推荐或购买数据库时便应该做到充分地考虑、讨论并得到妥善解决。

2.2 数据技术管理

　　DBA和其他数据专业人员管理这个领域的技术。管理数据技术应遵循其他技术管理同样的原则和标准。

　　当今领先的技术管理模型是[ITIL(信息技术基础设施库)，它是由英国开发的技术管理过程模型。ITIL原则适用于管理数据技术。关于ITIL更多信息,请参考ITIL网站http: // www.itil-officialsite. com。

2.2.1 理解数据技术需求

　　DBA不仅要了解数据技术工作原理,还要知道数据技术怎样能在特定业务境况下提供有效的价值。DBA应该与其他数据服务组织成员、业务人员、管理人员紧密合作了解业务对数据和信息的需求。这样使他们能就业务问题的技术应用提供良好的建议并及时挖掘新的商业机会。

　　数据专业人员在特定情况下决定选择用何种技术方案之前,必须了解数据技术的需求。以下问题是考虑数据技术适用性的出发点,但不限于此:

　　　　(1)该数据技术要解决的问题是什么?

　　　　(2)该数据技术可以提供其他数据技术没有的功能吗?

　　　　(3）该数据技术没有而其他数据技术可提供的功能?

　　　　(4)该数据技术是否需要特殊硬件要求?

　　　　(5）该数据技术是否有特别的操作系统需求?

　　　　(6）该数据技术是否需要特殊的软件或需要附加应用程序才能获得该数据技术所宣称的功能?

　　　　(7)该数据技术是否有特殊的存储需求?

　　　　(8)该数据技术是否对网络或连接有特殊需求?

　　　　(9）该数据技术是否包括数据安全功能?如果没有,其他什么工具能与其协作获得数据安全功能?

　　　　(10）该数据技术是否需要特殊技能来支持?我们是否已经拥有此类技术人才?是否需要从外面引进人才?

2.2.2 定义数据技术架构

　　数据技术是企业整体技术架构的组成部分,也被认为是数据架构的组成部分。数据技术架构解决以下3个基本问题:

　　　　(1)技术标准是什么(什么是必需的?什么是首选的?什么是可接受的?)?

　　　　(2)什么技术适用于什么目的和环境?

　　　　(3)在分布式环境中,使用了哪些技术?数据怎样从一个节点转移到移到另一个节点?

　　以下数据技术应该包括在技术架构中:

　　　　• 数据库管理系统(DBMS)软件。

　　　　• 相关数据库管理工具。

　　　　• 数据建模和模型管理软件。

　　　　• 报告分析的商务智能软件。

　　　　• 提取-转换-加载和其他数据整合工具。

　　　　• 数据质量分析和数据清理工具。

　　　　• 元数据管理软件,包括元数据存储库。

　　技术构架组件有时被称为“积木”。表达数据技术积木的分类或看法如下:

　　　　• 目前状态——支持和应用的现有产品。

　　　　• 部署阶段—在1～2年内将要部署应用的产品。

　　　　• 策略阶段—-在2年以后有可能应用的产品。

　　　　• 退役——企业已经退役的或今年打算退役的产品。

　　　　• 首选———被大多数应用程序首选使用的产品。

　　　　• 限制—仅限于某些应用程序的产品。

　　　　• 新兴一一正在研究的产品或有可能部署应用的先驱产品。

　　企业技术路线图包括评审、批准和发布“积木”。这有助于未来的技术决定。正确了解技术的多面性很重要:

　　　　• 永远没有免费午餐。即使是开源技术也需要维护和给养。

　　　　• 技术应被认为是达到目的的手段,而不该是目的本身。

　　　　• 最重要的是,购买与其他企业相同的软件,以同样的方式应用,却对企业没有产生业务价值和竞争优势。

　　在同业务人员,经理进行必要的讨论之后,数据服务组织要总结数据技术的业务目标，通过策略路线图的方式,有助于通知和指导未来的数据研究和项目工作。

2.2.3 评估数据技术

　　选择合适数据的相关技术,尤其是合适的数据库管理技术是数据管理的重要责任之一。管理层选择数据技术以满足业务需求,包括总成本、可靠性和集成性等。

　　选择合适的数据技术工作需要涉及到业务数据管理员、 DBA、数据架构员、数据分析师、其他数据管理专家和其他IT专业人士。需要调查和评估的数据技术包括:

　　　　• 数据库管理系统软件。

　　　　• 数据库辅助工具,比如备份和恢复工具、效率监控软件。

　　　　• 数据建模和模型管理软件。

　　　　• 数据库管理工具,比如编辑器、模式生成器和数据库对象生成器。

　　　　• 产生报告和分析用的商务智能软件。

　　　　• 提取-转换-加载(ETL)和其他数据整合工具。

　　　　• 数据质量和数据清理工具。

　　　　• 数据虚拟化工具。

　　　　• 元数据管理软件,包括元数据存储库。

　　此外,数据专家可能需要一些用于其他领域的特殊工具,包括:

　　　　• 变更管理(源码库和配置)工具。

　　　　• 问题和故障管理工具。

　　　　• 测试管理工具。

　　　　• 测试数据产生器。

　　利用标准的技术评估过程,并应用由Kepner和Tregoe在 The Rational Manager一书中定义的决策分析概念做决策选择。列出所有可能选项分别针对一系列带权重的决策标准做出比较,包括特征需求和功能目标,基本方法有以下步骤:

　　　　(1)了解用户需求、目标以及其他相关需要。

　　　　(2）对技术有概括性了解。

　　　　(3)确定可选技术方案。

　　　　(4)确定特征需求。

　　　　(5)对每一项特点进行权重分析。

　　　　(6)对每一个可选技术进行了解

　　　　(7)对每个可选技术方案的需求满足能力进行评估和打分。

　　　　(8)计算总分并对各个技术的评分排序。

　　　　(9)评估结果以及权重标准。

　　　　(10)展示选择最高积分的可选方案。

　　选择战略性DBMS 软件尤其重要。DBMS软件主要的影响在于数据整合,应用性能和DBA 的生产力。在选择 DBMS 软件时要考虑以下因素:

　　　　• 产品架构及复杂性。

　　　　• 应用资料(Profile),例如事务处理、商务智能以及个人资料。

　　　　• 企业对技术风险的承担程度。

　　　　• 硬件平台和操作系统支持。

　　　　• 软件支持工具的可用性。

　　　　• 性能基准。

　　　　• 可扩展性。

　　　　• 软件、内存及存储的需求。

　　　　• 训练有素的技术专业人员的供应量。

　　　　• 拥有成本,例如许可、维护和运算资源。

　　　　• 供应商的声誉。

　　　　• 供应商的支持政策和软件发布时间表。

　　　　• 用户参考。

　　DBA要负责评估各种可选技术。影响因素如下:

　　　　• 可选产品的可用性、稳定性,成熟度和当前产品的成本。

　　　　• 一个产品在满足现有业务需求/问题的适应性。

　　　　• 该产品满足其他业务需求的可扩展性。

　　　　• 该产品是否适合本公司的技术构架线路(见4.2.2节第4部分)。

　　　　• 该产品是否适合本企业其他产品和技术。

　　　　• 供应商的声誉,稳定性和预期寿命——公司是否有打算并有能力与此供应商在较长时间内合作?

　　　　• 对供应商支持度的期望——是否经常提供最低成本的更新?在需要时是否能得到供应商的帮助?

　　DBA要仔细认真地考虑各种候选产品的优缺点,实施和应用的难易程度,对现有的、将来业务需求及问题的适用性是否和供应商的宣传相符等。

2.2.4 安装和管理数据技术

　　DBA所面临的工作是部署新技术、产品到开发/测试、QA/验证和生产环境中。他们需要创建并编辑归档有关流程和规程,以最少的努力和开销管理产品。切记产品的开销包括管理、许可证和支持费等绝不能超过该产品对业务带来的价值。还要记住购买新产品,实施新技术不一定需要增加职员,所以新技术应该必须最大可能地实现自我监控和自我管理。

　　同样还要记住,对实施新技术的代价和复杂性通常估计不足,相反其功效和利益通常被过高估计。在进行大规模的产品项目实施之前,通过一个小规模的试点项目和概念验证(Proof of Concept,PoC)式实施,达到了解其真实花费和利益是一个很好的主意。

2.2.5 备案和跟踪数据技术的使用许可

　　公司必须遵守所有许可协议和法规需求。仔细跟踪并进行年度审计软件许可和年度支持费用,以及服务器租赁协议和其他固定费用等。违背许可协议会给组织带来严重的财务和法律风险。

　　数据也决定着各种技术和产品的总体拥有成本。定期评估过时的、厂商不再支持的,用处不大的或太昂贵的技术和产品。

2.2.6 支持数据技术的使用和问题

　　当业务需要新技术时,DBA将协同业务用户及应用开发人员一起工作,以确保最有效地利用该技术,探索新技术应用,并解决各种应用引起的问题或差错。

　　DBA和其他数据专业人员形成二级技术支持,协同服务台和技术供应商一起支持了解、分析和解决用户问题。

　　培训是做到有效地理解和应用各种技术的关键。企业应该针对每个参与实施人员、支持人员、使用数据人员,数据库技术人员制定有效的培训计划和预算。培训计划应该包括适当的交叉培训以保障更好的支持应用开发,特别是敏捷开发。DBA应该借此机会学习应用开发技术,例如类模型,用例分析,应用数据访问。开发人员应该学习某些数据库技巧,特别是SQL编码。

三、综述

　　在组织中实施数据操作管理的指导原则、每一个数据操作据管理活动相关角色的总结表,以及在数据操作管理中可能出现的组织和文化问题,总结如下。

3.1 指导原则

　　在Craig Mullins编著的《数据库管理》Database Administration)一书中指出,DBA主要遵循以下数据操作管理指导原则:

　　　　(1)记录所有事件。

　　　　(2）保留所有记录。

　　　　(3）尽可能程序自动化处理。

　　　　(4）集中理解每个任务的目的,管理范围,简化事情，一次做一件事。

　　　　(5)三思而后行。

　　　　(6）遇事不要慌张,反应沉着冷静,有理性,因为慌张会导致更多错误。

　　　　(7)不仅了解技术,也要了解业务。

　　　　(8）相互协作,提供帮助,彼此评审,共享知识。

　　　　(9)利用所有资源。

　　　　(10)持续更新。

3.2 过程总结

　　数据操作管理职能流程的过程总结如表6.1所示。表中列举了数据操作管理的每一项交付物、负责角色,批准角色和贡献角色。此表也在附录A.9中体现。

3.3 组织和文化问题

　　Q1:在数据库管理中,最常见的企业文化障碍是什么?

　　DBA通常不能把他们的工作价值有效地体现到企业中。他们需要认识到数据拥有者和消费者的法律责任,平衡短期需要和长期需要,对企业内其他人员进行教育,使他们懂得实行良好数据管理的重要性,优化数据开发操作以确保对企业的最大利益和对消费者最小影响。鉴于有关数据工作是一系列抽象的原理和操作,忽视人为因素介入的话, DBA 的风险传播被称为“我们vs他们”(即:对立)的心态问题,这样的心态是教条的、不切实际的和无益的,而且会成为解决问题的阻碍。

　　许多不连续性问题,大多数是架构参考冲突导致的问题。企业一般认为信息技术是一些特别的应用程序,而不是数据,并且常常是从应用为中心的角度看待数据。安全的、可再利用的,高质量的数据所带来的长期价值以及“将数据视为企业资源”的观点,通常还不被企业认可和重视。

　　应用开发人员经常视数据管理为应用开发的障碍,诸如延长项目开发周期和增加费用,并不带来额外效益。DBA对技术的改变适应较慢,例如 XML、对象和面向服务架构(SOA),以及新的应用程序开发方式,如敏捷开发、极限编程方法(XP)和 Scrum。另一方面,开发人员通常没有认识到良好的数据管理怎样帮助他们实现具有长期目标和目的、可重复再利用的程序和真正的面向服务的应用架构。

　　DBA 和其他数据管理人员可以通过以下几个方面来帮助克服这些企业和文化阻碍以促进更有效的合作方式来满足企业数据和信息需求:

　　　　• 数据库开发流程自动化,能缩短开发周期,减少错误和返工,减少对开发组的影响。在这种情况下, DBA 能适应更多应用程序的迭代(敏捷)开发方法。

　　　　• 开发和提倡抽象对象以及可重用数据对象,可避免应用程序与数据库模式的紧耦合-所谓的对象-关系阻抗失谐(Object-Relational impedance mismatch)。有一系列现有机制可用,包括数据库视图、触发器、函数和存储过程,应用数据对象和数据访问层、XML 和 XSLT,ADO. NET类型化的数据集以及网络服务。DBA应该熟悉所有数据虚拟化的途径并能对不同场合提出最好的建议。终极目标是令数据库使用得尽可能快速、方便和顺畅。

　　　　• 提倡以数据库标准和最佳实践作为工作要求,但也要有足够的灵活性,以免墨守成规。数据库标准永远不应该成为项目成功的威胁。

　　　　• 把数据库标准同服务水平协议支持水平相关联。例如,协议同时反映了那些 DBA的推荐和开发员接受的方法,以保证数据的完整性和安全性。如果开发组成员编写自己的数据库更新过程或数据访问层,那么服务水平协议应该反映从 DBA 到开发人员的责任转移。这将防止“全或无(All or Nothing)”的方式成为标准。

　　　　• 尽早地澄清项目的需求和支持需求可以降低项目组对数据组要求什么,不要求什么的误解。确保每个人都清楚DBA应该做什么,不应该做什么,并按要求完成工作;遵循或不遵循标准,项目的时间表,涉及的小时数和资源数,开发过程以及实施过程中需要的支持级别。这将有助于在开发过程中预防中途出现不愉快的意外。

　　　　• 不管是在开发阶段还是在实施以后,应同项目组持续地保持沟通以及时发现和解决所出现的问题。这包括校对数据访问代码、存储过程、视图,和由开发组员编写的数据库函数。这也有助于将数据库设计中的误解和问题呈现出来。

　　　　• 集中精力在业务上。项目的目的是满足业务需求和获得最大业务价值,而不是赢一次战斗却输掉一场战争。

　　　　• 采取“能做”的态度,最大限度地帮忙。如果你总是拒绝别人,那当别人忽略你而另找途径时,不要感到吃惊。要认识到人们做他们需要做的事,而你如果不帮他们获得成功,他们会使你失败。

　　　　• 把项目中遇到的任何失败和挫折当成教训,应用于将来的项目。你不必赢得每一场战斗,如果由于做错事而导致出现问题,你总有机会在以后给别人指出来要引以为鉴。

　　　　• 与人沟通要与对方的思考层面一致,并用对方的术语。同业务人员沟通最好用业务需求和投资回报术语,而开发人员则用面向对象、松散耦合,易于开发的术语。

　　　　• 集中精力解决他人的问题,而不是你自己的问题。

　　总而言之,我们需要了解谁是我们的利益相关者,他们的需求是什么?他们关心什么?我们需要设立一套清晰、简洁、实际、以业务为中心的标准,用最好的方式达到最佳.工作效果。此外,我们要传授和实施这些标准,为我们的利益相关者提供最大价值,从而赢得他们的尊敬,把我们作为支持者、贡献者和问题的解决者。

　　Q2:一个企业需要多少DBA?

　　不同企业对这个问题的答案各有不同。没有一个人员标准的经验法则。然而,如果人员过少,业务支出会明显增加。因为超负荷工作的 DBA容易出错,从而导致因停机运行问题造成的损失远高于减少DBA 人数省下的工资数。在考虑企业优化配置的DBA 数量时，有以下因素需要考虑:

　　　　• 数据库数量。

　　　　• 数据库规模和复杂性。

　　　　• DBMS平台和环境数量。

　　　　• 用户数量。

　　　　• 所支持的应用程序数量。

　　　　• 应用的类型和复杂性。

　　　　• 可用性的需求。

　　　　• 停机对业务的风险和影响。

　　　　• 性能的需求。

　　　　• 服务水平协议和相关客户期望。

　　　　• 数据库修改请求量。

　　　　• DBA人员的经验。

　　　　• 软件开发员的数据库经验。

　　　　• 终端用户经验。

　　　　• DBA工具的成熟度。

　　　　• DBA对数据库逻辑(存储过程,触发器、用户定义函数)、完整性、访问接口和信息产品的责任范围。

　　Q3:什么是应用DBA?

　　应用DBA负责一个或多个环境下的(开发/测试,QA和产品)数据库。有时,应用数据库DBA报告给所属组织的开发部门,该部门使用应用DBA管理数据库开发和维护应用程序。应用DBA职位有利有弊,应用DBA 被视为应用支持团队的成员之一,具体负责某些特定的数据库,他们能为开发人员提供良好的服务。然而,应用DBA很容易被隔离和丧失对企业整体数据的认识,以及常规DBA的实践。DBA,数据分析师、建模人员和架构师有必要保持长久的合作以防止 DBA 的隔离和孤立。

　　Q4:什么是过程 DBA?

　　一个过程 DBA要特别专注开发和支持DBMS所控制和执行的过程逻辑:存储过程、触发器和用户定义函数(UDF)。过程 DBA要确保这些过程逻辑有计划的实施、测试和共享(重用)。过程 DBA 负责评审和管理数据库的过程对象。

文末说明：参考书籍来自《DAMA数据管理知识体系指南》