本节书摘来自华章社区《DBA修炼之道：数据库管理员的第一本书》一书中的第2章，第2.1节定义企业的DBMS策略，作者（美）Craig S. Mullins，更多章节内容可以访问云栖社区“华章社区”公众号查看
2.1 定义企业的DBMS策略
为企业数据库管理选择适合的DBMS不像过去那样困难了。由于行业整合以及几大巨头的控制，主要DBMS供应商的数量随之减少。
为企业数据库管理选择适合的DBMS不像过去那样困难了。
然而，大中型企业通常会运行多种DBMS产品，从2～10种不等。例如，一家大型公司在大型机上使用IMS或IDMS和DB2，而在几台不同的UNIX服务器上使用Oracle和MySQL，在Windows服务器上使用Microsoft SQL Server。而且还在各种不同的平台安装其他的DBMS产品，如Sybase、Ingres、Adabas和PostgreSQL，以及单用户的PC DBMS产品，如Microsoft Access、Paradox和FileMaker。是谁安装了所有这些DBMS？为什么安装？
很不幸，答案通常是在决策时没有太多的思考和规划。有时候决定购买和安装一种新的DBMS是基于新业务或新应用程序的需要。如果企业没有DBMS而不得不购买一种，这是合乎情理的，但这样的情况很少。无论是否在用DBMS，通常认为新应用程序需要新的DBMS。有时候购买并安装了一种新的DBMS产品，但事先并没有评估该应用程序使用已有的DBMS能否部署成功。或者，更可能的是，DBA事先知道该应用程序可以使用已有的DBMS部署，但苦于没有权利或反对购买新DBMS的建议得不到支持。
还有其他的原因使一家企业存在多种DBMS平台。或许是公司购买的现成的商业应用程序包在已有的任何DBMS平台都不能运行。有时候决定购买新的DBMS是本着支持最新和最先进技术的打算。例如，许多大型机商家都摒弃了分层（IMS）或CODASYL（IDMS）数据库模型，进而选择了关系模型（DB2），导致需要学习并支持额外的DBMS。后来，随着C/S计算的流行，额外的DBMS也开始在UNIX、Linux和Windows服务器上部署了。
一旦DBMS安装成功，卸载就比较困难了，因为不同的DBMS之间不兼容以及可能还需要改变程序代码。此外，安装新的DBMS时，通常不会转移旧的应用程序和数据库。因此需要保留旧的DBMS继续提供支持。这使得DBA的工作变得复杂。
那么，该怎么做呢？应当赋予DBA团队决定企业DBMS的权力，并且没有DBA团队的同意，其他任何企业部门不得购买DBMS。然而，这样的条款势必难以实施和执行。企业政治经常针对DBA团队，因为相比其他的企业高管，DBA拥有较少的权力。
应当赋予DBA团队决定企业DBMS的权力。
2.1.1 DBMS选型
DBA团队应当就企业内部支持的DBMS产品设置一项政策，只要有可能，该政策应尽量减少不同DBMS产品的数量。拥有多种操作系统和多类型硬件的部门，选择默认的DBMS即可。除非有令人信服的业务案例，且通过了DBA团队的技术检验，否则不允许背离默认的DBMS。
大多数DBMS产品具有类似的功能，并且如果有些功能今天不存在，在接下来的18～24个月也会存在。因此，在为某个特定功能选择DBMS时务必小心谨慎。
从一级供应商选择DBMS产品。
DBMS选型时，明智的做法是在一级供应商中选择，如表2-1所列。一级代表最大的供应商，拥有市面上大量部署和支持的产品。使用DB2或Oracle不会出错，因为二者都很受欢迎并且支持几乎任何类型的数据库。另一种主要的产品是Microsoft SQL Server，但仅适用于Windows平台。DB2和Oracle可以在多种平台上运行，从大型机到UNIX、Windows甚至手持设备。在特定情况下才会选择这三种之外的DBMS产品。
当然，市场上还有其他DBMS产品，其中不乏优秀的产品值得考虑用作专业处理、某种预定义的需求以及其他合适的事情。如果你的企业斥巨资进入开源软件领域，PostgreSQL、EnterpriseDB或MySQL会是可行的选择。如果目标DBMS对于一个具体项目非常重要，你可能会考虑ObjectDesign或Versant。同时还有多种NoSQL DBMS产品，如Hadoop、Cassandra和MongoDB。
选择任何级别较低的产品可能招致意外风险。
然而，对于大多数的数据管理需求，任何来自一级或者二级DBMS供应商的DBMS产品都将提供足够的功能且风险很低。可用的DBMS产品很多，且每种都有某些功能值得具体分析对待。选择任何级别较低供应商的产品（即使像Software AG的Adabas和Actian的Ingres这样响当当的名字）可能招致意外风险。DBMS供应商列表请参阅附录B。
我不希望这听起来好像DBMS选型一样不需要费脑筋，为你的具体情况选择适合的DBMS还是需要制订策略和计划的。DBMS选型时，一定要注意如下这些因素：
对操作系统的支持。DBMS是否支持企业使用的操作系统，包括目前使用的和计划使用的版本？
企业的类型。DBMS选型时要考虑企业的理念。有些企业非常保守，它们喜欢严格控制环境，因此这些企业倾向于传统的大型机环境。政府运作、金融机构、保险和保健公司往往倾向于保守派。更多自由派企业往往愿意考虑其他架构，这种情况在一些不那么保守的企业并不少见，如制造企业、网络公司和大学。最后，有些公司根本不信任将Windows作为关键任务的环境，它们更愿意使用UNIX。这就排除了一些数据库供应商（尤其是Microsoft SQL Server）。
基准。什么性能基准对于DBMS供应商和DBMS的其他用户是可用的？事务处理性能委员会（TPC）公布的官方数据库性能基准，可用作许多不同类型的数据库处理性能整体上的基本指导方针。（更多细节请参考“事务处理性能委员会”。）一般来说，性能基准作为一种广泛的数据库性能指标可能有用，但不应该是DBMS选型时的唯一决定因素。许多TPC基准遇到的数据库部署并不能代表大多数的生产数据库系统，因此并不能表明特定的DBMS的实际性能。此外，基准也在不断更新，以表明每种主要的DBMS产品新的改进的性能测量，使得基准的“赢家”过时很快。
基准在不断更新以表明新的和改进的性能测量。
可扩展性。DBMS支持你准备部署的数据库规模和用户数量吗？大型数据库如何建立、支持和维护呢？容易还是痛苦？有独立用户可以确认DBMS供应商所声称的可扩展性吗？
支持软件工具的可用性。你所要求的支持工具在该DBMS上可用吗？这些支持工具可能包括：查询和分析工具、数据仓库支持工具、数据库管理工具、备份和恢复工具、性能监控工具、容量规划工具、数据库实用工具，以及支持各种编程语言。
技术人员。是否有足够熟练的DBMS数据库专家?考虑有关DBA、技术支持人员（系统程序员和管理员、操作分析员等）和应用程序编写人员的所有需求。
购置成本。DBMS的总购置成本是多少？DBMS供应商疯狂地为他们的技术收取费用，总购置成本应该结合DBMS的许可证成本，为DBMS编程、提供支持、提供管理的数据库专家的成本，操作DBMS所需的计算资源成本。
发布计划。DBMS供应商发布新版本的频率如何？有效供应商的发布周期很快，每12～18个月就会更新版本。这可以是好事也可以是坏事，看你怎么想。如果你想要尖端的功能，这就是好事。相反，如果你所在的企业相对保守，那么会难以应对DBMS经常变化。快速发布周期会导致那些保守的企业要么以超过它们期许的频率更新DBMS，要么使用过时的DBMS软件，但这不可能得到与最新的DBMS软件相同水平的支持。
参考客户。DBMS供应商是否提供当前的用户参考？靠你自己能否找到可以给出相对公允答案的其他用户？与当前用户谈话可能会发现被你忽略的问题和关注点。供应商提供的支持如何？他们能否很好地回应问题？使用效果和他们所宣传的一致吗？经常会有许多bug修复必要应用吗？新版本的质量如何？这些问题恐怕只有亲身使用过的人才能回答。
事务处理性能委员会
事务处理性能委员会（TPC）是一个独立的、非盈利性组织，它掌管并管理着性能基准测试。它的使命是定义事务处理和数据库基准，给业界提供客观的、可验证的性能数据。TPC基准衡量并评估电脑的功能和操作。
TPC所信奉的“事务”的定义是偏业务的。典型的TPC事务包括数据库为某些事情而做的更新，比如，库存控制（货物）、飞机票预订（服务）和银行业（货币）。
TPC产生的基准衡量性能的依据是：在单位时间内，一个给定的系统和数据库可以执行多少事务，例如，每秒的事务数量。TPC定义了三种基准：
TPC-C，交易环境中计划的生产工作量。
TPC-H，决策支持基准，由一系列面向业务的随机查询和并发的数据修改组成。
TPC-E，一种更新的OLTP工作量（基于金融事务处理）。
有关这些基准的更多信息和深层次定义请参考TPC的网站：www.tpc.org（详见图2-1）。
DBMS选型一定要考虑产品的复杂性。DBMS软件一般都比较复杂且随着每一个新版本的发布会变得越来越复杂。过去通过附加软件或独立程序才支持的功能也越来越多地添加到DBMS的功能特征中，如图2-2所示。你需要规划并支持所有这些功能特征。因为即使目前没有某些特定功能的需求，一旦部署DBMS，程序员和开发人员也会找到理由来使用这些供应商添加的所有功能。所以做好规划和准备总比事先没有规划而直接使用更好些。
2.1.2 DBMS架构
DBMS环境的支撑架构对数据库应用程序的成功至关重要。一个错误的选择或整体架构的某个组件部署错误都会导致应用程序性能低、停机或不稳定。
DBMS环境的支撑架构对数据库应用程序的成功至关重要。
以大型机为主的企业计算，当时单纯关注DBMS架构即可。一切都运行在大型机上，事实如此。然而，当今的IT基础设施是分布式的和异构的，整体架构（即使是大型机DBMS）也可能由多个平台和互操作系统软件组成。由业务和IT专家组成的团队，而不是个人或单个组，来制定最终的架构决策。业务专家应包括来自各部门的代表，以及负责软件合同问题的会计和法律部门。除了数据库管理代表（DA、DBA和SA），网络组成员、操作系统专家、经营管理人员、编程专家，以及其他任何相关人员，都应在这个团队中。
此外，要确保所选的DBMS适合计划部署处理的性质和类型。DBMS架构有四个级别：企业、部门、个人和移动。
企业DBMS是专为可扩展性和高性能而设计的。企业DBMS必须能够支持非常大型的数据库、大量的并发用户和多种类型的应用程序。它运行在大型机器上，通常是主机或运行UNIX、Linux或Windows服务器的高端服务器。此外，企业DBMS提供了来自DBMS供应商的所有附加功能。多处理器支持、支持并发查询以及其他高级DBMS功能，都是企业DBMS的核心组成部分。
DBMS架构有四个级别：企业、部门、个人和移动。
部门DBMS有时也称作工作组DBMS，服务于中间地带。它为组织内部的小到中等规模的工作组提供支持，通常情况下，运行在UNIX、Linux或Windows服务器上。部门数据库服务器和企业数据库服务器之间的分界线不是很明显。通过软硬件升级可以让部门DBMS处理任务，之前这些任务可能只由企业DBMS执行。部门软硬件组件成本的稳步下降还有助于降低运营的总成本，并扩展工作组环境以服务于整个企业。
个人DBMS专为个人用户设计，通常用于中低端Powered PC平台。Microsoft Access、SQLite和FileMaker都是个人数据库软件的例子。当然，主要DBMS供应商也销售功能更强大的解决方案的个人版本，如Oracle数据库个人版和DB2个人版。有时个人DBMS的低成本会误导人试图为部门或企业解决方案选择个人DBMS。然而，不要经不起低成本的诱惑，个人DBMS产品只适用于规模非常小的项目，多用户应用程序绝对不可部署。
最后，移动DBMS是部门或企业DBMS的特别版本，专为那些不常接入网络的远程用户设计。移动DBMS允许通过笔记本电脑或手持设备访问和修改本地数据库，此外，它还提供了将远程数据库更改同步到一个集中的企业或部门数据库服务器的一种机制。
为一种类型的事务处理而设计的DBMS可能不适合其他用途。例如，个人DBMS不是为多用户设计的，而企业DBMS对于个人用户来说一般太复杂。务必弄清楚企业、部门、个人和移动DBMS软件之间的区别，然后选择适合你的特定数据处理需求的DBMS。可能需要选择多个DBMS类型——每个级别选一个DBMS——具体使用则由每个开发项目的需求来定。
如果你的企业需要不同级别的DBMS，那么尽可能从同一家供应商选择一组DBMS解决方案会是不错的选择。这么做有助于减少访问、开发和管理时的差异。例如，如果你的企业使用Oracle的企业DBMS，那就不妨选择Oracle的个人版来满足个人用户DBMS的需求。
2.1.3 DBMS集群
集群是利用多个“独立的”计算系统作为单一的、高度可用的系统一同工作。现代DBMS提供集群支持用以提高可用性和可扩展性。集群的两种主要架构是磁盘共享和无共享，这些命名至少在一定水平上很好地描述了架构的本质。
现代DBMS提供集群支持用以提高可用性和可扩展性。
无共享集群如图2-3所示。在这种架构中，每个系统都有属于各自的资源（内存、磁盘等）。集群处理器是通过连接计算机的网络传递信息来沟通的。此外，来自客户端的请求自动被路由至拥有所请求资源的系统。每次只有一个集群系统可以“拥有”并访问特定的资源。当发生故障时，资源所有权可以自动转移到集群中的其他系统。无共享集群的主要优势是它的可扩展性，理论上，一台无共享的多处理器可以扩展至上千台处理器，因为它们相互之间互不干涉，即没有共享。
无共享集群的主要优势是可扩展性。
共享磁盘集群更适用于大型机环境中的大规模企业处理。
在共享磁盘环境中，所有连接的系统共享同一个磁盘设备，如图2-4所示。每个处理器仍然有自己独立的内存，但所有的处理器都可以直接寻址所有的磁盘。通常情况下，共享磁盘集群不为较小的机器扩展，这与无共享集群不同。共享磁盘集群更适用于大型机环境中的大型企业处理。大型机（特别是非常大的处理器）能处理大量的工作，只有少数集群大型机就可以获得很大的收益，而多台PC和中型处理器一起才能实现类似的收益。
主要DBMS供应商都提供支持不同类型且具有不同能力和需求的集群。例如，用于z/OS的DB2提供共享磁盘集群，具有数据共享和并行系统综合体的能力；非大型机平台的DB2则使用无共享集群；Oracle的Real Application Clusters提供共享磁盘集群。
对于大多数用户来说，集群的主要好处是增强可用性，这归结于组合处理器。在某些情况下，集群可以帮企业达到99.999%的可用性。此外，集群可用于负载均衡和容错。
2.1.4 DBMS泛滥
作为一个经验法则，创建策略必须要赶在企业引入新的DBMS之前，否则会导致不同的DBMS产品泛滥，从而难以支持。也会造成困惑，如哪个部署使用哪个DBMS。
不同DBMS产品的泛滥可能难以支持。
正如前面提到的，DBMS供应商过剩且各自贩卖各自的产品。作为DBA，你势必会遭受市场和销售人员的狂轰滥炸，试图说服你使用他们的DBMS。一定要扛住，除非他们能给出非常有吸引力的理由，并提供短期投资回报率（ROI）的证明。即使有正当的理由且ROI良好，也要仔细推敲他们所说的以及ROI的计算方法。有时一些理由是过时的且没有考虑周全ROI，如额外的管理成本。
记住，每个DBMS都需要数据库管理支持。此外，每个DBMS使用不同的方法来执行类似的任务。因此，安装的DBMS产品越少，数据库管理越简单，为企业提供有效的数据管理资源的机会就越好。
2.1.5 硬件问题
建立应用开发的数据库环境时，DBMS选型只是整个工程的一部分。未来DBMS以运行的硬件和操作系统会极大地影响数据库环境的可靠性、可用性和可扩展性（RAS）。例如，运行z/OS的大型机平台IBM zEC12与一个运行AIX的中档IBM xSeries设备相比，前者可能会提供更高的RAS，而后者却可能会超过运行Windows的Dell服务器。这并不是说一切都应运行在大型机上，而必须还要考虑其他问题，如成本、体验、可管理性以及所要开发的应用程序的需求。底线是确保将硬件平台和操作系统这些限制因素计入DBMS选型的标准。
将硬件平台和操作系统这些限制因素计入DBMS选型的标准。
2.1.6 云数据库系统
云计算（见“云计算概述”）应用越来越多广泛，特别是在中小型企业中。与建立一整套需要管理和支持的本地计算基础设施相比，云服务部署的成本效益可能更好。
云数据库系统通过互联网提供DBMS服务。权衡本质上归结为信任将数据的存储和管理任务交由云服务提供商，作为企业帮助减少数据库管理和维护成本和精力的回报。使用云数据库系统可以使企业，尤其是规模较小且没有资源在企业计算基础设施上投资的企业，专注自己的业务而不用担心他们的计算环境。
通过整合云数据源，可能会促进合作伙伴、分支机构、远程工作人员和移动设备之间的协作，因为作为一种服务，使得数据变得更容易访问。不需要安装、设置、打补丁或管理DBMS软件，因为这些管理任务都由云服务提供商掌管和关心。不足之处是，你的数据现在由一个外部代理云服务提供商存储和控制。云计算的另一种固有风险是可能会有一些不法代理商假装合法用户。
云数据库平台的例子是Microsoft SQL Azure，它建立在SQL Server技术的基础之上，是Windows Azure平台的一个组成部分。
云计算概述
在较高层次上，云计算是作为一种服务而提供的计算。云计算应用程序依赖网络（通常是互联网）为用户提供共享资源、软件和数据。有了云计算，计算机系统和应用程序的作用都应像公共事业提供商（如电网）一样。
云一词用来比喻互联网，这基于在绘制基础设施图时常倾向于将网络访问画作一个抽象的“云”。这方面的例子可参考本书第1章的图1-11。
从DBMS的角度来看，云计算将数据及其管理从本地的计算环境移走，并通过互联网将计算作为一种服务来提供。
