Oracle数据库云化整合方案

1、Oracle数据库云化整合方案整合最佳实践：借助 Oracle Database 进入云时代目 录TOC o 1-2 h z u HYPERLINK l _TOC_250023 概要2 HYPERLINK l _TOC_250022 企业云之旅3 HYPERLINK l _TOC_250021 通过标准化降低复杂性4 HYPERLINK l _TOC_250020 整合降低成本并提高可管理性5 HYPERLINK l _TOC_250019 通过 Oracle Database 12c 实现整合6 HYPERLINK l _TOC_250018 新式多租户架构的主要优势6 HYPERLINK

2、l _TOC_250017 选择整合方式8 HYPERLINK l _TOC_250016 PDB 如何解决 IT 复杂性问题8 HYPERLINK l _TOC_250015 选择合适的隔离级别9 HYPERLINK l _TOC_250014 隔离及其对整合的影响9 HYPERLINK l _TOC_250013 可插拔数据库整合10 HYPERLINK l _TOC_250012 数据库整合13 HYPERLINK l _TOC_250011 整合多个 CDB15 HYPERLINK l _TOC_250010 模式整合17 HYPERLINK l _TOC_250009 云池设计19

3、HYPERLINK l _TOC_250008 CPU19 HYPERLINK l _TOC_250007 内存21 HYPERLINK l _TOC_250006 存储22 HYPERLINK l _TOC_250005 互补性负载23 HYPERLINK l _TOC_250004 Oracle Enterprise Manager 12c Cloud Management Pack25 HYPERLINK l _TOC_250003 Consolidation Planner25 HYPERLINK l _TOC_250002 执行所有供应活动的 Database Provisionin

4、g 控制台26 HYPERLINK l _TOC_250001 计费26 HYPERLINK l _TOC_250000 总结27概要传统上，IT 组织将各个数据库和应用程序部署在专用服务器基础架构上，以支持不同的部门或业务线 (LOB)。技术与业务职能部门之间的这种细分式协调不仅导致技术基础架构利用率极低，而且管理这种部署的管理资源利用率也很低。此外，这种孤岛式部署还抑制了 IT 组织快速响应不断变化的业务需求的能力。为应对这些挑战，许多组织正利用企业私有云来实现成本节省，同时提高业务敏捷性。这种向云计算模型的转移涉及到多项变革。整合是这一历程中的关键步骤之一，它可以提高资源利用率，降低资本

5、支出和运营支出，从而帮助组织提高运营效率。实现这些节省的关键是实现标准化以及减少需要管理的不同环境的数量。Oracle Database 12c 为整合应用程序负载提供了巨大优势。这些优势包括：简化管理 减少需要管理的不同环境的数量。多合一管理。简化供应和打补丁易于整合 无需更改应用程序即可实现整合。在本文中，我们将介绍这些功能并说明 Oracle Database 12c 如何帮助执行整合以及加快您的云之旅。企业云之旅您有时会听到这种说法，云计算是整合的代名词。事实并非如此！整合是云计算的基石， 但企业云则提供了更多功能。确实，企业有望通过云计算提高敏捷性、降低风险、减少成本，但是，这一美好

6、前景的实现取决于您采用的方法。Oracle 以最全面、现代化和安全的系列云产品和服务为您提供多样的选择和灵活性，以满足您的所有业务需求并实现云计算的全部优势。要完全转型到企业云，可能需要几年时间，而且将会对组织及角色、流程、策略和服务交付的许多方面产生影响。Oracle 已经看到许多企业采用一种阶段性的方法（企业云之旅） 来组织实施该转型。在该旅程中，企业逐步完成一系列独立的阶段，每个阶段都是在已有基础上可实现的并且将会提供巨大的优势。这样，无论每个组织选择的旅程有多快或多远， 他们甚至从初始阶段开始即可获得立杆见影的价值。图 1. 企业云之旅Oracle Database 12c 旨在支持企

7、业云，并提供新特性以便在该旅程的每个阶段提供主要优势。Oracle 白皮书“通过 Oracle Database 12c 加快企业云之旅 1”介绍了这种阶段性方法。1 HYPERLINK /technetwork/database/database-cloud/journey-to-enterprise-cloud-wp-1959164.pdf /technetwork/database/database-cloud/journey-to-enterprise-cloud-wp- HYPERLINK /technetwork/database/database-cloud/journey-to

8、-enterprise-cloud-wp-1959164.pdf 1959164.pdf本白皮书侧重于整合阶段，将着重介绍 Oracle Database 12c 可以带来的好处，不过我们将略微谈及标准化以及通过降低复杂性可以得到的好处。通过标准化降低复杂性标准化是成功实现企业云的基础。在标准化阶段，通过从自定义部署转变为高度标准化的部署来达到降低复杂性的目标。应使用几个标准化服务来处理大多数服务请求。您需要了解您当前的孤岛式 IT 环境及其包含的所有内容，然后寻找机会进行简化和实现标准化：基础架构组件（硬件和软件）、服务、流程以及供应商。实现标准化的一个主要好处是能够减少您所管理的环境的多样

9、性，从而降低管理开销。在大多数情况下，这将直接节省运营支出 (OpEx)。对 OpEx 的影响取决于您的环境实现标准化的效率。标准化服务 创建构建块这一阶段的主要可交付成果是，定义最少的一系列标准化服务，以便以最少的标准化服务支持大多数业务请求。标准化服务是易于支持的基本构建块。一个标准化服务可与其他标准化服务结合使用来构建更高级别的业务服务。以下是一家大型金融机构的标准化服务示例，其中定义了白金级、黄金级和白银级数据库服务级别。图 2. 一家大型金融机构提供的标准化服务请注意，尽管标准化服务提供了更高的效率，但是确实还需要保持一定程度的灵活性，以便在需要时可以提供自定义服务。整合降低成本并提

10、高可管理性整合决策常常是在执行其他计划后才制定，而且常常是出于成本节省才加以考虑。这些计划可能包括公司旨在减少电力消耗的“绿色”环保计划。通过提高硬件利用率抵消资本支出；降低运营成本：电力、空间、管理。可以通过优质的整合战略实现所有这些目标，这听起来很不错，但如果将整合视为构建可以在其上开发企业云的平台的话，则可以实现更多的目标。数据库整合可能最初是作为业务计划的主要驱动力。对于许多客户来说，他们别无他愿， 只希望得到整合阶段的成果；成本节省，包括初期和持续成本节省，对于他们来说就足够了。可是，一旦整合完成，并且落实了未来支持此方法的实践，整合就不一定是最终目标了。整合，以及对 IT 环境及其

11、提供的服务实施标准化，只不过是一个开端。成本节省将会随之而来。通过将数据库服务2 整合到共享基础架构，您可以提高该基础架构的利用率并减少硬件服务器占用的空间。通过将标准化数据库服务整合到共享环境，您可以进一步提高利用率，并且因为这样可以减少您需要管理的不同环境的数量，所以可以显著降低管理成本。这既会降低资本支出又会降低运营支出。您将能够实现多方面的节省： 降低电力消耗、减少数据中心占用空间、降低 IT 管理支出，这里仅举几例。2 数据库服务代表具有共同的属性、服务级别阈值及优先级的应用程序组。数据库服务提供单一系统映像来管理相互竞争的应用程序，并允许将每个负载作为一个单元进行管理。一个数据库服

12、务可以跨越一个 Oracle 数据库或一个全局集群中的多个数据库的一个或多个实例，而一个实例可以支持多个数据库服务。通过 Oracle Database 12c 实现整合Oracle Database 12c 引入了一些旨在帮助进行数据库整合的特性。在 Oracle Database 12c 之前，模式整合可以提供最高程度的整合。但是，在模式整合方式下，为了确保整合应用程序能够共存，需要进行仔细的考虑和规划。这种情况下必须避免模式命名空间冲突，必须确认打包应用程序的认证，等等。模式整合并不总是易事一桩， 修改应用程序以检测和纠正侵权情况可能十分困难、代价高昂甚至无法做到。模式整合的好处十分明显

13、，但是许多客户无法实现这种整合。Oracle Database 12c 引入了一种新的架构，这种架构通过消除以往模式整合存在的所有局限，极大地简化了将多个应用程序整合到一个共享数据库环境的过程。这种新的架构称作多租户架构，利用这种架构，您可以部署一个多租户容器数据库 (CDB)，而这个容器数据库则可以包含一个或多个可插拔数据库 (PDB)。这种新的架构随 Oracle Multitenant 而提供。Oracle Multitenant 是 Oracle Database 12c 企业版的一个新选件，它简化了整合与供应，提供了更快的升级和迁移方法（这里仅举几例），从而可以帮助客户降低 IT 成

14、本。AdvancedSecurity 选件中的增强可以为整合环境提供保护，同时不会影响性能。通过将您的专用环境作为可插拔数据库整合到 Oracle Real Applications Cluster (RAC) 多租户容器数据库中，可以提高可用性，并提供灵活性以帮助满足不断变化的业务需求。新式多租户架构的主要优势整合密度高。单个 CDB 中的多个 PDB 将共享该容器数据库的内存和后台进程，从而相对于部署专用的单实例数据库而言，您能够在一个特定服务器平台上运行更多 PDB。这与模式整合具有同样的好处。但是值得注意的是，多租户架构消除了在采用基于模式的整合时存在的障碍，并且消除了随着该方法而来的

15、持续的运营问题。使用 SQL 简化供应和克隆。您可以将一个 PDB 从 CDB 中拔出然后再将其插入到另一个CDB 中。此外，还可以在同一个 CDB 中克隆 PDB，或从一个 CDB 克隆到另一个 CDB 中。这些操作，以及创建 PDB 的操作，可以使用新的 SQL 命令来完成，并且只需几秒就可以完成。如果底层文件系统支持精简供应，那么通过在 SQL 命令中使用关键字 snapshot 几乎瞬间即可克隆数 TB 的数据。快速修补和升级的新范式。修补一个 CDB 即可修补其包含的所有 PDB。要修补单个PDB，您只需跨 Oracle 数据库软件版本边界拔出/插入它即可。数据库多合一管理。通过将现

16、有数据库作为 PDB 进行整合，管理员可以将多个数据库作为一个整体来进行管理。例如，可以在 CDB 级执行诸如备份和灾难恢复等任务。可插拔数据库之间的动态资源管理。Oracle Database 12c Resource Manager 扩展了特定功能， 能够即时控制 CDB 中 PDB 之间的资源争用。提高可用性和弹性。利用 PDB 的拔出/插入功能，可以更快地执行需要停机执行的硬件迁移。相比一组独立的专用数据库的故障切换操作，CDB 及其包含的许多 PDB 的故障切换操作能够更快地完成。提高安全性。针对所有主要安全特性（ 包括 Oracle Database Vault 、Transpar

17、ent DataEncryption、Unified Auditing 和 Database Firewall）的更轻松的配置和更好的性能增强。Oracle Database Vault、Unified Auditing 和 Transparent Data Encryption 可以在 PDB 级进行配置。我们在论及 Oracle Multitenant、Advanced Security 和 Oracle Enterprise Manager 12c CloudManagement 组件时将提供有关整合的更多详情。选择整合方式整合的业务动因并未考虑到各个应用程序的需求。选择哪些应用程序可以

18、置于同一个共享环境中并不总是一件简单的任务，但是通过仔细考虑一些关键因素，可以对大多数应用程序实现整合的优势。在我们继续讨论之前，首先考虑重要的一点。整合的意思并不是说要将所有数据库置于虚拟机中。虚拟化在很多情况下是以虚拟孤岛取代物理孤岛。这并不会降低 IT 复杂性。PDB 如何解决 IT 复杂性问题根据 IT 基础架构库 (ITIL)，配置项 (CI) 被定义为需要加以管理以提供 IT 服务的任何组件。我们来看看在一个拥有 8 个数据库，每个数据库分别运行于各自专用环境中的数据中心中存在多少个 CI。这里有 8 个 Oracle 数据库实例、8 个操作系统映像和 8 台独立的服务器。就是说共

19、有 24 个 CI 需要进行管理、监视、修补和备份。对于这些资产的平均利用率，没有什么可以说道的。如图 3 所示，8 个专用数据库，分别运行于各自的孤岛环境中。图 3. 8 个专用数据库环境在下面的图 4 中，我们将这 8 个专用数据库整合到了一个 Oracle RAC CDB 中，该 CDB 运行于一个有 2 个节点的集群中。该 CDB 包含 8 个 PDB，我们在每个实例上开启了（举例来说）4 个 PDB。在本例中，我们将 CI 数量减至 14 个：8 个 PDB、2 个 CDB 实例、2 个操作系统映像和 2 个节点，从而大大减少了需要管理的组件数量。此外，由于我们只需监视和管理 14

20、个 CI，并且在 CDB 级执行修补和备份任务，因此需要管理甚至更少的 CI 组件。图 4. Oracle RAC CDB 包含 8 个 PDB，每个实例上开启 4 个 PDB如本例所示，资产利用率将会提高，而处理开销将会下降。Oracle Database 12c 同时解决了服务器泛滥和 CI 泛滥这两个问题。选择合适的隔离级别租户间的隔离要求是影响整合方法选择的一个重要因素，并且对可实现的整合程度有很大的影响。就资源共享来说，隔离与灵活性是相互对立的两个方面。共享的环境可带来更大的灵活性、更低的管理开销和更高的资源利用率；而更高程度的隔离则会尽可能减少安全问题，减少应用程序间整合的考虑事项

21、（例如，这可能影响何时可以对数据库进行升级）；在共享环境与更高的隔离度之间有个利弊权衡的问题。通常的建议是只按照需要进行隔离，以满足特定部署的租户隔离要求。隔离要求一般与政府规定或法规要求有关，但也可能包括数据库或操作系统版本限制等要求。隔离及其对整合的影响隔离可能是物理上的隔离，也可能是逻辑上的隔离，可以在以下四个方面进行考虑：故障隔离、安全性隔离、资源隔离和运营隔离。图 5. 资源共享有助提高效率是利用 PDB 将多个应用程序整合到一个数据库中，将多个数据库托管到一个平台上，还是结合使用这两种方法？选择哪种方法将取决于您的整合战略需要的隔离程度。每种整合方式对待隔离的方法稍有不同，可以结合

22、使用 Oracle Database 12c 和操作系统功能，以及其他高级特性和产品。本节将重点讨论私有数据库云中的租户隔离，将对数据库整合、模式整合以及可插拔数据库整合部署方式进行比较。可插拔数据库整合在这种方式下，一些应用程序作为 PDB 整合到同一个 CDB 中来运行。可以供应多个CDB，每个 CDB 可以在一个云池中的一个或多个服务器上运行3。这种方式下租户的粒度是 PDB。Oracle Database 12c 在单个 CDB 中最多支持 252 个PDB。此外，在一个给定的 CDB 上最多可以创建 1024 个动态数据库服务，相比于将专用数据库整合到一个共享平台，或者通过一些独立的

23、 VM 整合到一个共享服务器的做法，这会带来更高的规模效益。3 云池是一组拥有共享存储并共享一个专用网络的服务器。因此，云池可以是一个 OracleClusterware 集群，或者一个虚拟服务器池。私有云是一些云池的集合。图 6. 整合到多租户架构图 6 所示为单个容器数据库包含五个可插拔数据库。该 CDB 运行于一个 Oracle RAC 集群中，在该集群中，对各个 PDB 的访问通过一个或多个实例上提供的相关服务来进行。故障隔离一个 PDB 中的应用程序故障不会影响同一 CDB 中的其他 PDB。因为该应用程序的活动限制于其连接到的 PDB 中。资源隔离资源隔离处理系统资源的分配和分离。

24、如果在同一节点上存在多个活动 CDB，则争用的资源包括 CPU、内存和 I/O（存储容量以及 IOP）。按照数据库整合方法：内存 在 每 个 实 例 的 基 础 上 设 置 合 适 的MEMORY_TARGET 和MEMORY_MAX_TARGET 值，注意这些值必须对同一数据库的所有实例保持一致。MEMORY_TARGET 不会对 PGA 值强加硬性限制。强烈建议不要过量使用内存资源。较为保守的目标是，同一个节点上的所有数据库不要分配超过 75% 的可用内存。在 Exadata 硬件上：OLTP 负载：CDB 的 (SGA_TARGET + PGA_AGGREGATE_TARGET) 总数

25、+ 4 MB *（最大进程数） 每个数据库节点的物理内存数据仓库负载：CDB 的 (SGA_TARGET + 3 *PGA_AGGREGATE_TARGET) 总数 每个数据库节点的物理内存CPU 通过使用 CPU_COUNT 或启用实例囚笼4 设置合适的值。建议采用后一种方法，因为通过使用实例囚笼可强制实施某种 Database Resource Manager (DBRM) 资源计划，从而能够更多地掌控 CPU 使用量。多租户架构对 Resource Manager 进行了扩展，允许使用 CDB 级计划管理 PDB 之间的资源争用。整合应用程序时，在 Resource Manager 配置

26、文件中使用 UTILZATION_LIMIT 是一种好的做法。通过对资源使用进行限制，当向原先内容稀少的 CDB 中添加更多应用程序时， 该 CDB 中原有应用程序的用户不会感到性能有什么变化。Oracle Database Quality of Service Management (QoS Management) 对应用程序之间共享的资源进行管理，并调整系统配置以保持应用程序运行于业务需要的性能级别。将一些 PDB 整合到单个 CDB 中可能导致定向到某给定节点（或实例）的客户端会话数量增加。举例来说，当由于故障切换或中间层配置不合适而出现大量并发连接尝试或出现登录风暴时，可能会影响其他整

27、合应用程序。登录风暴将表现为资源短缺现象，但是在严重的情况下可能导致调度冲突及其他连锁故障。为了尽量减少登录风暴的影响，需要恰当地配置中间层连接池，并且仔细考虑提供服务的位置。此外，可以配置 Oracle Listener 来限制连接速率。运营隔离在 PDB 方式下，尽量减少恢复/还原丢失数据的影响非常重要，同样地，尽量减少补丁应用和升级的影响也很重要。PDB 带来的多合一管理方法允许对每个 CDB 自动调度执行备份，同时也允许单独恢复某个给定 PDB。PDB 时间点恢复 操作不会影响其他共存的 PDB。目前尚不支持 PDB 闪回。4 有关实例囚笼的详细信息，请参阅本文中标题为“云池设计”的一

28、节打补丁在整合环境中对数据库进行修补涉及两项任务：规划补丁应用以及实际应用补丁。应预先树立这样的见识：一次性或非计划的修补工作效率不高，因此不应鼓励这样的做法。应当为补丁应用（如 Oracle 补丁集更新 (PSU)）预定一个时间计划并且必须让租户知道这一计划。话虽如此，还是应作好应用一次性补丁的准备，但是必须对这些补丁对相应 CDB 中所有租户的影响进行评估。如果只有一个或少数几个应用程序 (PDB) 需要紧急应用一次性补丁，则最高效的补丁应用方法是创建一个包含这些额外补丁的新的 CDB，然后使用拔出/插入操作将这些 PDB 逐个迁移到该 CDB 中。注意这会增加需要管理的组件数量，不过这在

29、短期内可能是可以承受的。安全性在任何整合环境中采用“最低权限”方法都将为加强安全性提供最大助益。在大多数情况下，单个 Oracle Home 将托管相应节点中运行的所有数据库。这意味着，任何操作系统用户，只要是该 Oracle Home 的 DBA 组的成员，就都拥有对该主目录中运行的所有数据库实例的 SYSDBA 访问权限。从易于管理的角度来讲这是个不错的方法，但这确实会引发安全性问题。我们建议实施以下最佳实践：尽量降低对数据库服务器的访问权限。只允许 SQL*Net pipe 访问。为所有 DBA 创建具名用户账户，对特权命令提供 sudo 访问权限为跨多个 PDB 的管理任务创建通用用户

30、o除了为运行管理任务而需要的对象（如一些过程）之外， 通用用户不应拥有任何其他对象。使用角色来限制特权；保持对 SYSDBA 和 SYSOPER 的有限的访问权限。Oracle Database 12c 为备份管理、Oracle Data Guard 管理和加密密钥管理提供了额外的管理角色， 这些角色分别是： SYSBACKUP、SYSDG 和SYSKM。您可酌情使用这些角色。启用 Oracle Database Vault 以提供角色分离并控制数据访问可以对 E-Business Suite、Siebel 和 PeopleSoft 使用预先定义的数据领域。对静态数据进行加密数据库整合在数据库

31、整合方式下，各个数据库整合到聚集在一个云池中的物理服务器上。该池中的任何服务器均可托管一个或多个 Oracle 数据库实例。通过使用 Oracle RAC 或 Oracle RAC One Node，这些数据库会继承服务器冗余带来的高可用性。通过向池中添加更多服务器或者向给定节点或实例添加更多 CPU、内存或 I/O 卡， 可以实现弹性和可伸缩性。尽管标准化十分重要，但确实需要容许例外情况，这样，添加更大（更高容量）的节点， 以及组成异构集群（从节点的 CPU 或内存配置角度）也都是可行的。故障隔离这种整合方式的粒度是数据库。每个数据库及其相关实例都与同一池中的其他数据库相隔离。某个给定实例上

32、发生的故障一般局限于该实例本身，即使这些数据库可能运行于同一Oracle Home 中。但是，可能会出现这样一些状况：因单个实例无响应而可能导致影响多个实例的结果；典型的需要节点重启的状况。通过应用程序设计和实施最佳实践可以限制实例或节点故障的影响。例如，通过使用动态数据库服务和连接池，并结合使用快速应用程序通知 (FAN) 功能，应用程序能够更快速地响应中断事件，从而限制了这些事件的影响。资源隔离资源隔离处理系统资源的分配和分离。在数据库整合方式下，争用的资源包括 CPU、内存和 I/O（存储容量以及 IOP）。内存 在 每 个 实 例 的 基 础 上 设 置 合 适 的MEMORY_TAR

33、GET 和MEMORY_MAX_TARGET 值，注意这些值必须对同一数据库的所有实例保持一致。MEMORY_TARGET 不会对 PGA 值强加硬性限制。强烈建议不要过量使用内存资源。在 Exadata 硬件上：OLTP：CDB 的 (SGA_TARGET + PGA_AGGREGATE_TARGET) 总数 + 4MB *（最大进程数） 每个数据库节点的物理内存DW：CDB 的 (SGA_TARGET + 3 * PGA_AGGREGATE_TARGET) 总 数 每个数据库节点的物理内存CPU 通过使用 CPU_COUNT 或启用实例囚笼5设置合适的值。建议采用后一种方法，因为通过使用实

34、例囚笼可强制实施某种 Database Resource Manager (DBRM) 资源计划，从而能够更多地掌控 CPU 使用量。5 有关实例囚笼的详细信息，请参阅本文中标题为“云池设计”的一节运营隔离运营隔离确保对一个数据库或其运行环境执行的管理或维护操作不会影响同一云池中正在运行的其他数据库。这些活动包括启动和关闭实例、修补以及备份或恢复操作。启动/关闭通常只使用一个或最少数量的 Oracle Home 来托管所有整合数据库。应为每位云 DBA 创建具 名 用 户 ， 然 后 将 这 些 用 户 添 加 到 数 据 库 口 令 文 件 （ 必 须 将REMOTE_LOGIN_PASSW

35、ORDFILE 设置为 EXCLUSIVE）。这些具名用户于是被授予了SYSDBA 角色。通过为每个数据库使用不同的口令文件，即可保证用户只能获得自己管理的数据库的 SYSDBA 权限。打补丁与 PDB 整合方式相同，在整合环境中对数据库进行修补涉及两项任务：规划补丁应用以及实际应用补丁。应预先树立这样的见识：一次性或非计划的修补工作效率不高，因此不应鼓励这样的做法。应当为补丁应用（如 Oracle 补丁集更新 (PSU)）预定一个时间计划并且必须让租户知道这一计划。话虽如此，还是应作好应用一次性补丁的准备，但是必须对这些补丁对整个数据库的影响进行评估。最高效的修补方法是克隆 Oracle H

36、ome 目录，应用补丁，然后将数据库实例切换到新的主目录。而在 RAC 环境中，如果提供了滚动补丁，则应使用它们来进行滚动修补。安全隔离同见 PDB 整合一节讨论的内容。整合多个 CDB在数据库一级，上文所述的数据库负载整合与大小设置原则同样适用于将多个 CDB 和专用数据库整合到共享云池上的情形。不过，您必须根据每个 CDB 中包含的 PDB 的数量， 以及要整合到云池上的 CDB 与专用数据库的混合情况，来增加服务器和操作系统大小设置原则。选择将哪些数据库整合到一起的一般性原则主要取决于您与数据库云租户达成的服务级别协议 (SLA)。在基础架构一级，总而言之，要将这些 SLA 与最适合实现

37、这些 SLA 的云池相对应。这些云池本身则应使用标准化硬件和软件组件来构建并且应为它们设置合适的大 小，以便支持预先确定的整合密度和隔离策略。例如，图 7 所示为一个数据库云部署，这里某个云池中的一组服务器划分为了三个服务器池，分别托管三个通过策略管理的6 CDB。在本例中，每个 CDB 可代表一个使用不同的字符集，处于不同的补丁级别，或者属于不同的业务线之类的数据库。图 7. 利用 Oracle Database 12c 进行数据库整合在进行 CDB 整合时，我们建议您预先确定针对每个数据库的策略并在提供服务时执行这些策略。每个 CDB 拥有最大数量的 PDB确定每个云池托管的 CDB 和/

38、或专用数据库的最大数量在部署过程中严格执行这些策略将会为您带来均匀一致的环境。这样的环境将有利于实现更轻松的自动化和生命周期管理。6 通过策略管理的部署以服务器池 为基础，这种情况下，在一个服务器池中运行的数据库服务将作为跨该服务器池中所有服务器的单一对象或统一体来运行。数据库部署于一个或多个服务器池中，服务器池的大小决定了相应部署中数据库实例的数量。模式整合在这种整合方式下，整合的数据库包含跨云池中一个或多个实例而运行的一个或多个应用程序模式。已实施此方法的客户往往将应用程序（模式）的数量限制为少于 20。这种方式下租户的粒度是模式。故障隔离一个模式中的应用程序故障不会影响其他模式中的应用程

39、序。登录风暴或不合适的中间层配置可能影响多个应用程序。为了限制这种影响，使用配置合适的中间层连接池是十分重要的。编写不良的数据库驻留代码（如 PL/SQL）可能影响其他不相关的应用程序。因而在开发过程中必须进行严格的代码检查，在应用程序部署之前必须进行彻底的测试。资源隔离对于模式整合来说，资源管理是一项必要的工作。Oracle Database Resource Profile Limits 为限制资源使用提供了一个基本方法。通过设置资源限制，可以防止用户执行令系统繁忙的操作并防止其他用户执行操作。注意您还可以使用资源限制来加强安全性，确保用户退出系统后会话不会长期留置于连接状态。 Datab

40、ase Resource Manager (DBRM) 和 QoSManagement 提供了对 Resource Profile 的补充。可以将应用程序分组到不同的用户组中，这些用户组采用相应的 DBRM 资源计划指令。资源计划控制分配给用户组的 CPU、I/O（在 Exadata 部署中）和并行服务器进程资源。对存储使用的控制则可以通过使用表空间配额来进行。运营隔离在模式整合方式下，尽量减少恢复和还原操作的影响是运营隔离的一个主要目标，补丁应用管理也是如此。为了实现尽可能最高效的数据恢复，必须仔细设计备份策略。备份方法应该包含对应用 程序来说恰当的恢复粒度。典型的方法是对各个模式进行夜间备

41、份和 Data Pump 导出。利用闪回方法（表、查询或事务级闪回）可以恢复已丢失或删除的数据，这种恢复过程 具有最低的侵入性。如果数据已从闪回区域老化掉，则还可以使用恢复表包来帮助恢复 丢失的数据。修补方法类同于其他整合方式中讨论的方法。安全隔离模式间的安全隔离是模式整合最重要的一个方面。可以使用 Oracle 数据库配置文件来限制对数据的访问，但是大多数情况下必须制定更严格的安全措施和策略。始终保护静态数据（通过加密技术），提供细粒度访问控制以及实施安全审计。这些实践活动意味着需要使用透明数据加密、Database Vault 领域，以及用于运行时审计管理的 Oracle Audit Va

42、ult and Database Firewall。此外，还应实施以下最佳实践：限制 SYSDBA、SYSOPER 及 SYSASM 访问权限。根据需要利用 SYSBACKUP 和SYSDG 角色。确保使用专用同义词。避免使用公共同义词。必须使用强数据库口令，并为 PASSWORD_LOCK_TIME和FAILED_LOGIN_ATTEMPTS 设置适当的值。云池设计云池的初始大小将取决于其托管的应用程序的类型以及这些应用程序各自的容量要求。大多数情况下，私有云将由一些较小的云池组成，而不会只是一个池。云池应符合以下需求：业务需求为各个业务线或部门构建独立的云池为不同的 SLA、合规性要求，或

43、测试与开发构建独立的云池功能需求为具有类似功能的应用程序构建一个云池。例如，分别为内部应用程序和外部应用程序构建一个云池技术需求根据操作系统类型、数据库版本或隔离需求构建独立的云池。考虑各种负载之间的互补性云池常常使用特定的配置来构建并且支持特定的业务需求。最佳的做法是，将具有类似SLA 需求的应用程序共置于一个整合环境中，而将关键应用程序与非关键应用程序混置于同一个云池中则一般是不合适的。可整合的应用程序数量取决于将要整合的应用程序的大小、资源使用量和 SLA。此外，应设置预定义的系统资源使用量阈值，这将决定云池的容量。建议使用标准模块化构建块构建云池。许多客户都选择基于四节点集群实现标准化

44、，因为这为服务布置和应用程序负载增长提供了灵活性，并且通过为计划中断和组件故障防范提供更多选择而提高了可用性。下面介绍对物理资源的配置：CPU最初确定 CPU 的大小时，要确定将托管哪些应用程序，并且要留有一些余地，包括 10% 的运营任务开销（如备份或调度任务等），以及用于负载故障切换的 15% 的开销。云池中的工作节点保持在 75% 的 CPU 容量内，这样可以在一般使用量与余量之间达到良好的平衡。图 8. CPU 容量云池中供应的一个数据库（CDB 或非 CDB7 ）应至少获得两个 CPU。此配置可以使用CPU_COUNT 参数（在 init.ora 文件中设置）或实例囚笼特性8 来实施

45、。实例囚笼特性，尽管也使用 CPU_COUNT 参数进行设置，但是还有通过 Database Resource Manager 实施资源使用限制的额外好处。实例囚笼用于对同一机器上数据库间的 CPU 使用进行划分。这些数据库可以是两个或更多个 CDB、非 CDB 或两者的组合。分区与过度供应实例囚笼能够减少多个共享相同服务器的数据库实例间对 CPU 资源的争用现象。这是通过对调度执行特定实例相关进程的 CPU 的最大数量进行设置的。这既可用于 CDB 也可用于7 注意非 CDB 这一术语指的是曾使用 Oracle Database 11g 或更早版本的人们所熟悉的那种数据库架构。Oracle

46、Database 12c 既支持多租户架构也支持非 CDB 架构。8 有关实例囚笼的详细讨论，请见 HYPERLINK /technetwork/database/focus- /technetwork/database/focus- areas/performance/instance-caging-wp-166854.pdf非 CDB。有两种方法可以确定 CPU 的最大数量：分区与过度供应。分区 CPU采用分区方法时，给定节点上的所有数据库实例的 CPU_COUNT 设置总和不会超过 CPU 总数。对于任务关键型应用程序，我们建议采用此方法，如果使用 QoS Management，也需要采

47、用此方法。使用这种配置时，数据库实例间不会存在 CPU 资源争用。但是如此一来，即使某个数据库实例未使用分配给它的 CPU 资源，其他数据库实例也无法使用这些资源。在对 CPU 进行分区时，应采用以下建议，这能确保诸如 Oracle Clusterware 及其代理、ASM 等关键进程可以获得 CPU 资源：(CPU_COUNT) 总和 CPU 总数 * 75%过度供应 CPU采用过度供应方法时，所有实例的 CPU_COUNT 总和可以超过 CPU 的总数。过度供应方法可以提高资源的利用率，然而，当多个数据库同时处于高负载状况时，可能会出现资源争用的情况，从而导致性能下降。对于运行非关键应用程

48、序的系统、测试或开发系统、或者运行没有严格 SLA 要求的任何数据库的系统来说，建议采用过度供应方法。而对于 I/O 要求较高或事务处理速度较高的数据库来说，则应避免使用过度供应方法。我们建议：(CPU_COUNT) 总和 = CPU 总数 * 2允许分配两倍 CPU 总数是以每核 2 个 CPU 线程这种超线程技术为基础的。当对 CPU:线程比率大于 2 的系统（例如，Oracle Sun T4 系统的每 CPU 的线程计数可以高达 64 个线程） 使用过度供应方法时，应加以注意。在 Exadata 数据库云服务器上运行的数据库可以配置为使用更高程度的过度供应。有关最新建议，请参阅最新的“E

49、xadata 最佳实践”白皮书。此外，请将最大并行查询服务器数量限制为小于或等于 CPU 或线程总数的 20 倍。内存在云池中，内存的配置比 CPU 大小配置更简单：不要过量使用内存资源。对于有待整合的现有数据库，可使用 AWR 报告、V$SGASTAT/V$PGASTAT 或 Enterprise Manager Automatic Memory Advisor 确定 SGA 和 PGA 内存。对于新应用程序，执行基本的 大 小 配 置 测 试 之 后 ， 将 MEMORY_TARGET 设 置 为 较 为 保 守 的 值 ， 将MEMORY_MAX_TARGET 设置为较为激进的值。下面是

50、关于内存占用的一般性原则：获得 SGA/PGA 信息之后，每次迁移或布置到某个云池之前进行如下评估：OLTP 应用程序：数据库的 (SGA_TARGET + PGA_AGGREGATE_TARGET) 总量 每个数据库节点的物理内存的 80%DW/BI 应用程序：数据库的 (SGA_TARGET + 3 * PGA_AGGREGATE_TARGET) 总数 每个数据库节点的物理内存的 80%要注意的是，数据库整合方式并不能最高效地使用内存，因为每个数据库实例都将占用自己的 SGA 和 PGA。而 PDB 整合方式则能最高效地使用内存，因为在云池中配置了具有整合 SGA 的单一大型数据库实例。存

51、储云 DBA 应在整合之前检查现有应用程序的存储使用情况。通常为孤岛式数据库分配的存储超过其实际使用的存储，因此需要检查的一个关键项目就是所分配的存储实际得到使用的有多少，也就是说，有多少是空闲的，有多少包含数据。如果存在存储分配过量的情况， 那么这也许是一个整合存储空间的好机会。可以使用 Oracle Data Pump 或任何可以在逻辑上迁移数据的工具进行这种整合。DBA 应研究数据增长方式，为此可以使用 EM 12c，逐个表空间/数据文件地评估模式的存储增长方式。除此之外，在将应用程序迁移到私有云之前，应用程序所有者还应确保清理数据库中过时或无用的数据。这不仅能提高存储效率， 还能缩短整

52、体迁移时间。存储 IOPS 或许是整合环境中最常被忽视的一个方面。在整合规划过程中，DBA 应观察待整合的每个数据库或应用程序的平均和峰值 IOPS。使用 AWR 报告收集以下 I/O 量度。IOPS = “physical reads total I/O requests” + “physical writes total I/O requests”MBytes/s = “physical reads total bytes” + “physical writes total bytes”这些量度有助于确定为了支持相应应用程序而需要的存储吞吐能力。如果现有应用程序在RAC 上运行，则应聚合所

53、有节点的 IOPS 或者说 MB/s。互补性负载私有数据库云部署取得成功的一个关键要素就是确保仅合并互补性负载。混合非互补性或不相容的负载可能导致整合环境性能不佳、SLA 得不到满足，甚至出现中断。整合负载时，应确保所整合的负载的峰值 CPU 使用量不会显著超出平均 CPU 使用量。峰值 CPU 使用量与平均 CPU 使用量之间的差异应最小，这样确保 CPU 可得到尽可能充分的利用。在对整合环境中将包含的负载进行评估时，需要观察由于新增负载而产生的峰值和平均CPU 使用量的改变。合并互补性负载时，平均负载的增加程度将超过峰值的增加，如图 9 所示。最好的情况是，峰值使用量保持不变，而平均使用量

54、增加。图 9. 互补性负载如图 10 所示，在负载不相容的情况下，峰值的增加将超过平均值的增加。这意味着，在低使用量期间，CPU 利用率低下，但是为了能够承担峰值负载，必须保有这些 CPU。图 10. 不相容的负载您可以使用 Real Application Testing (RAT) 来确定新增负载将会对现有系统产生的影响。RAT 适用于所有整合方式：PDB 整合、数据库整合以及模式整合。利用整合数据库重放(Consolidated Database Replay)，可以并行地重放在不同数据库上捕获到的负载。这样，您可以收集从一个或多个系统捕获到的负载，然后在单个测试系统上并行地重放这些负载

55、。在整合数据库重放的帮助下，您可以评估数据库整合将会对生产系统产生的影响，评估单个服务器，如一台 Oracle Exadata 服务器，能否处理来自整合数据库的合并负载。利用负载折叠 (Workload Folding) 功能，您可以合并负载并同时重放它们，而利用时间推移(time shifting) 功能，则可以对齐各种负载峰值。有关 Real Application Testing 的更多信息可参阅“Oracle Database Testing Guide 12c Release 1 (12.1)”。Oracle Enterprise Manager 12c Cloud Management Pack作为 Oracle 的集成式企业 IT 管理产品，Oracle Enterprise Manager 12c 提供了业界首个全面的云生命周期管理解决方案。EM 12c 的业务驱动型 IT 管理功能为您提供从应用程序到磁盘的支持，允许您快速搭建、管理和支持企业云环境和传统 Oracle IT 环境。Oracle Cloud Management Pack for Oracle Database 为整个数据库云生