Oracle数据库云化整合方案整合最佳实践：借助 Oracle Database 进入云时代
目录
概要 (2)
企业云之旅 (3)
通过标准化降低复杂性 (4)
整合降低成本并提高可管理性 (5)
通过Oracle Database 12c 实现整合 (6)
新式多租户架构的主要优势 (6)
选择整合方式 (8)
PDB 如何解决IT 复杂性问题 (8)
选择合适的隔离级别 (9)
隔离及其对整合的影响 (9)
可插拔数据库整合 (10)
数据库整合 (13)
整合多个CDB (15)
模式整合 (17)
云池设计 (19)
CPU (19)
内存 (21)
存储 (22)
互补性负载 (23)
Oracle Enterprise Manager 12c Cloud Management Pack (25)
Consolidation Planner (25)
执行所有供应活动的Database Provisioning 控制台 (26)
计费 (26)
总结 (27)
概要
传统上，IT 组织将各个数据库和应用程序部署在专用服务器基础架构上，以支持不同的部门或业务线(LOB)。技术与业务职能部门之间的这种细分式协调不仅导致技术基础架构利用率极低，而且管理这种部署的管理资源利用率也很低。此外，这种孤岛式部署还抑制了IT 组织快速响应不断变化的业务需求的能力。
为应对这些挑战，许多组织正利用企业私有云来实现成本节省，同时提高业务敏捷性。这种向云计算模型的转移涉及到多项变革。整合是这一历程中的关键步骤之一，它可以提高资源利用率，降低资本支出和运营支出，从而帮助组织提高运营效率。实现这些节省的关键是实现标准化以及减少需要管理的不同环境的数量。
Oracle Database 12c 为整合应用程序负载提供了巨大优势。这些优势包括：
1. 简化管理—减少需要管理的不同环境的数量。
多合一管理。
2. 简化供应和打补丁
3. 易于整合—无需更改应用程序即可实现整合。
在本文中，我们将介绍这些功能并说明Oracle Database 12c 如何帮助执行整合以及加快您的云之旅。
企业云之旅
您有时会听到这种说法，云计算是整合的代名词。事实并非如此！整合是云计算的基石，但企业云则提供了更多功能。
确实，企业有望通过云计算提高敏捷性、降低风险、减少成本，但是，这一美好前景的实现取决于您采用的方法。Oracle 以最全面、现代化和安全的系列云产品和服务为您提供多样的选择和灵活性，以满足您的所有业务需求并实现云计算的全部优势。
要完全转型到企业云，可能需要几年时间，而且将会对组织及角色、流程、策略和服务交付的许多方面产生影响。Oracle 已经看到许多企业采用一种阶段性的方法（企业云之旅）来组织实施该转型。在该旅程中，企业逐步完成一系列独立的阶段，每个阶段都是在已有基础上可实现的并且将会提供巨大的优势。这样，无论每个组织选择的旅程有多快或多远，他们甚至从初始阶段开始即可获得立杆见影的价值。
图1. 企业云之旅
Oracle Database 12c 旨在支持企业云，并提供新特性以便在该旅程的每个阶段提供主要优势。Oracle 白皮书“通过Oracle Database 12c 加快企业云之旅1”介绍了这种阶段性方法。
1 https://www.doczj.com/doc/378753984.html,/technetwork/database/database-cloud/journey-to-enterprise-cloud-wp- 1959164.pdf
本白皮书侧重于整合阶段，将着重介绍Oracle Database 12c 可以带来的好处，不过我们将略微谈及标准化以及通过降低复杂性可以得到的好处。
通过标准化降低复杂性
标准化是成功实现企业云的基础。
在标准化阶段，通过从自定义部署转变为高度标准化的部署来达到降低复杂性的目标。应使用几个标准化服务来处理大多数服务请求。
您需要了解您当前的孤岛式IT 环境及其包含的所有内容，然后寻找机会进行简化和实现标准化：基础架构组件（硬件和软件）、服务、流程以及供应商。
实现标准化的一个主要好处是能够减少您所管理的环境的多样性，从而降低管理开销。在大多数情况下，这将直接节省运营支出(OpEx)。对OpEx 的影响取决于您的环境实现标准化的效率。
标准化服务—创建构建块
这一阶段的主要可交付成果是，定义最少的一系列标准化服务，以便以最少的标准化服务支持大多数业务请求。标准化服务是易于支持的基本构建块。一个标准化服务可与其他标准化服务结合使用来构建更高级别的业务服务。
以下是一家大型金融机构的标准化服务示例，其中定义了白金级、黄金级和白银级数据库服务级别。
图2. 一家大型金融机构提供的标准化服务
请注意，尽管标准化服务提供了更高的效率，但是确实还需要保持一定程度的灵活性，以便在需要时可以提供自定义服务。
整合降低成本并提高可管理性
整合决策常常是在执行其他计划后才制定，而且常常是出于成本节省才加以考虑。这些计划可能包括公司旨在减少电力消耗的“绿色”环保计划。通过提高硬件利用率抵消资本支出；降低运营成本：电力、空间、管理。
可以通过优质的整合战略实现所有这些目标，这听起来很不错，但如果将整合视为构建可以在其上开发企业云的平台的话，则可以实现更多的目标。
数据库整合可能最初是作为业务计划的主要驱动力。对于许多客户来说，他们别无他愿，只希望得到整合阶段的成果；成本节省，包括初期和持续成本节省，对于他们来说就足够了。可是，一旦整合完成，并且落实了未来支持此方法的实践，整合就不一定是最终目标了。整合，以及对IT 环境及其提供的服务实施标准化，只不过是一个开端。
成本节省将会随之而来。通过将数据库服务2 整合到共享基础架构，您可以提高该基础架构的利用率并减少硬件服务器占用的空间。通过将标准化数据库服务整合到共享环境，您可以进一步提高利用率，并且因为这样可以减少您需要管理的不同环境的数量，所以可以显著降低管理成本。这既会降低资本支出又会降低运营支出。您将能够实现多方面的节省：降低电力消耗、减少数据中心占用空间、降低IT 管理支出，这里仅举几例。
2 数据库服务代表具有共同的属性、服务级别阈值及优先级的应用程序组。数据库服务提供单一系统映像来管理相互竞争的应用程序，并允许将每个负载作为一个单元进行管理。一个数据库服务可以跨越一个Oracle 数据库或一个全局集群中的多个数据库的一个或多个实例，而一个实例可以支持多个数据库服务。
通过Oracle Database 12c 实现整合
Oracle Database 12c 引入了一些旨在帮助进行数据库整合的特性。
在Oracle Database 12c 之前，模式整合可以提供最高程度的整合。但是，在模式整合方式下，为了确保整合应用程序能够共存，需要进行仔细的考虑和规划。这种情况下必须避免模式命名空间冲突，必须确认打包应用程序的认证，等等。模式整合并不总是易事一桩，修改应用程序以检测和纠正侵权情况可能十分困难、代价高昂甚至无法做到。模式整合的好处十分明显，但是许多客户无法实现这种整合。
Oracle Database 12c 引入了一种新的架构，这种架构通过消除以往模式整合存在的所有局限，极大地简化了将多个应用程序整合到一个共享数据库环境的过程。这种新的架构称作多租户架构，利用这种架构，您可以部署一个多租户容器数据库(CDB)，而这个容器数据库则可以包含一个或多个可插拔数据库(PDB)。这种新的架构随Oracle Multitenant 而提供。
Oracle Multitenant 是Oracle Database 12c 企业版的一个新选件，它简化了整合与供应，提供了更快的升级和迁移方法（这里仅举几例），从而可以帮助客户降低IT 成本。Advanced Security 选件中的增强可以为整合环境提供保护，同时不会影响性能。通过将您的专用环境作为可插拔数据库整合到Oracle Real Applications Cluster (RAC) 多租户容器数据库中，可以提高可用性，并提供灵活性以帮助满足不断变化的业务需求。
新式多租户架构的主要优势
整合密度高。单个CDB 中的多个PDB 将共享该容器数据库的内存和后台进程，从而相对于部署专用的单实例数据库而言，您能够在一个特定服务器平台上运行更多PDB。这与模式整合具有同样的好处。但是值得注意的是，多租户架构消除了在采用基于模式的整合时存在的障碍，并且消除了随着该方法而来的持续的运营问题。
使用SQL 简化供应和克隆。您可以将一个PDB 从CDB 中拔出然后再将其插入到另一个CDB 中。此外，还可以在同一个CDB 中克隆PDB，或从一个CDB 克隆到另一个CDB 中。这些操作，以及创建PDB 的操作，可以使用新的SQL 命令来完成，并且只需几秒就可以完成。如果底层文件系统支持精简供应，那么通过在SQL 命令中使用关键字snapshot 几乎瞬间即可克隆数TB 的数据。
快速修补和升级的新范式。修补一个CDB 即可修补其包含的所有PDB。要修补单个PDB，您只需跨Oracle 数据库软件版本边界拔出/插入它即可。
数据库多合一管理。通过将现有数据库作为PDB 进行整合，管理员可以将多个数据库作为一个整体来进行管理。例如，可以在CDB 级执行诸如备份和灾难恢复等任务。
可插拔数据库之间的动态资源管理。Oracle Database 12c Resource Manager 扩展了特定功能，能够即时控制CDB 中PDB 之间的资源争用。
提高可用性和弹性。利用PDB 的拔出/插入功能，可以更快地执行需要停机执行的硬件迁移。相比一组独立的专用数据库的故障切换操作，CDB 及其包含的许多PDB 的故障切换操作能够更快地完成。
提高安全性。针对所有主要安全特性（包括Oracle Database Vault 、Transparent Data Encryption、Unified Auditing 和Database Firewall）的更轻松的配置和更好的性能增强。Oracle Database Vault、Unified Auditing 和Transparent Data Encryption 可以在PDB 级进行配置。
我们在论及Oracle Multitenant、Advanced Security 和Oracle Enterprise Manager 12c Cloud Management 组件时将提供有关整合的更多详情。
选择整合方式
整合的业务动因并未考虑到各个应用程序的需求。选择哪些应用程序可以置于同一个共享
环境中并不总是一件简单的任务，但是通过仔细考虑一些关键因素，可以对大多数应用程
序实现整合的优势。
在我们继续讨论之前，首先考虑重要的一点。整合的意思并不是说要将所有数据库置于虚
拟机中。虚拟化在很多情况下是以虚拟孤岛取代物理孤岛。这并不会降低IT 复杂性。
PDB 如何解决IT 复杂性问题
根据IT 基础架构库(ITIL)，配置项(CI) 被定义为需要加以管理以提供IT 服务的任何组件。
我们来看看在一个拥有8 个数据库，每个数据库分别运行于各自专用环境中的数据中心中存在多少个CI。这里有8 个Oracle 数据库实例、8 个操作系统映像和8 台独立的服务器。就是说共有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 个CI，并且在CDB 级执行修补和备份任务，因此需要管理甚至更少的CI 组件。
图4. Oracle RAC CDB 包含8 个PDB，每个实例上开启 4 个PDB
如本例所示，资产利用率将会提高，而处理开销将会下降。Oracle Database 12c 同时解决了
服务器泛滥和CI 泛滥这两个问题。
选择合适的隔离级别
租户间的隔离要求是影响整合方法选择的一个重要因素，并且对可实现的整合程度有很大的影响。就资源共享来说，隔离与灵活性是相互对立的两个方面。共享的环境可带来更大的灵活性、更低的管理开销和更高的资源利用率；而更高程度的隔离则会尽可能减少安全问题，减少应用程序间整合的考虑事项（例如，这可能影响何时可以对数据库进行升级）；在共享环境与更高的隔离度之间有个利弊权衡的问题。
通常的建议是只按照需要进行隔离，以满足特定部署的租户隔离要求。隔离要求一般与政
府规定或法规要求有关，但也可能包括数据库或操作系统版本限制等要求。
隔离及其对整合的影响
隔离可能是物理上的隔离，也可能是逻辑上的隔离，可以在以下四个方面进行考虑：故障
隔离、安全性隔离、资源隔离和运营隔离。
图5. 资源共享有助提高效率
是利用PDB 将多个应用程序整合到一个数据库中，将多个数据库托管到一个平台上，还是结合使用这两种方法？选择哪种方法将取决于您的整合战略需要的隔离程度。每种整合方式对待隔离的方法稍有不同，可以结合使用Oracle Database 12c 和操作系统功能，以及其他高级特性和产品。
本节将重点讨论私有数据库云中的租户隔离，将对数据库整合、模式整合以及可插拔数据库整合部署方式进行比较。
可插拔数据库整合
在这种方式下，一些应用程序作为PDB 整合到同一个CDB 中来运行。可以供应多个CDB，每个CDB 可以在一个云池中的一个或多个服务器上运行3。这种方式下租户的粒度是PDB。
Oracle Database 12c 在单个CDB 中最多支持252 个PDB。此外，在一个给定的CDB 上最多可以创建1024 个动态数据库服务，相比于将专用数据库整合到一个共享平台，或者通过一些独立的VM 整合到一个共享服务器的做法，这会带来更高的规模效益。
3 云池是一组拥有共享存储并共享一个专用网络的服务器。因此，云池可以是一个Oracle Clusterware 集群，或者一个虚拟服务器池。私有云是一些云池的集合。
图 6. 整合到多租户架构
图6 所示为单个容器数据库包含五个可插拔数据库。该CDB 运行于一个Oracle RAC 集群中，在该集群中，对各个PDB 的访问通过一个或多个实例上提供的相关服务来进行。
故障隔离
一个PDB 中的应用程序故障不会影响同一CDB 中的其他PDB。因为该应用程序的活动限制于其连接到的PDB 中。
资源隔离
资源隔离处理系统资源的分配和分离。
如果在同一节点上存在多个活动CDB，则争用的资源包括CPU、内存和I/O（存储容量以及IOP）。按照数据库整合方法：
?内存—在每个实例的基础上设置合适的MEMORY_TARGET 和MEMORY_MAX_TARGET 值，注意这些值必须对同一数据库的所有实例保持一致。MEMORY_TARGET 不会对PGA 值强加硬性限制。强烈建议不要过量使用内存资源。较为保守的目标是，同一个节点上的所有数据库不要分配超过75% 的可用内存。在Exadata 硬件上：
o OLTP 负载：CDB 的(SGA_TARGET + PGA_AGGREGATE_TARGET) 总数+ 4 MB *（最大进程数）< 每个数据库节点的物理内存
o数据仓库负载：CDB 的(SGA_TARGET + 3 *
PGA_AGGREGATE_TARGET) 总数< 每个数据库节点的物理内存?CPU —通过使用CPU_COUNT 或启用实例囚笼4 设置合适的值。
建议采用后一种方法，因为通过使用实例囚笼可强制实施某种Database Resource Manager (DBRM) 资源计划，从而能够更多地掌控CPU 使用量。
多租户架构对Resource Manager 进行了扩展，允许使用CDB 级计划管理PDB 之间的资源争用。整合应用程序时，在Resource Manager 配置文件中使用UTILZATION_LIMIT 是一种好的做法。通过对资源使用进行限制，当向原先内容稀少的CDB 中添加更多应用程序时，该CDB 中原有应用程序的用户不会感到性能有什么变化。
Oracle Database Quality of Service Management (QoS Management) 对应用程序之间共享的资源进行管理，并调整系统配置以保持应用程序运行于业务需要的性能级别。
将一些PDB 整合到单个CDB 中可能导致定向到某给定节点（或实例）的客户端会话数量增加。举例来说，当由于故障切换或中间层配置不合适而出现大量并发连接尝试或出现登录风暴时，可能会影响其他整合应用程序。登录风暴将表现为资源短缺现象，但是在严重的情况下可能导致调度冲突及其他连锁故障。
为了尽量减少登录风暴的影响，需要恰当地配置中间层连接池，并且仔细考虑提供服务的位置。此外，可以配置Oracle Listener 来限制连接速率。
运营隔离
在PDB 方式下，尽量减少恢复/还原丢失数据的影响非常重要，同样地，尽量减少补丁应用和升级的影响也很重要。
PDB 带来的多合一管理方法允许对每个CDB 自动调度执行备份，同时也允许单独恢复某个给定PDB。PDB 时间点恢复操作不会影响其他共存的PDB。目前尚不支持PDB 闪回。
4 有关实例囚笼的详细信息，请参阅本文中标题为“云池设计”的一节
打补丁
在整合环境中对数据库进行修补涉及两项任务：规划补丁应用以及实际应用补丁。应预先树立这样的见识：一次性或非计划的修补工作效率不高，因此不应鼓励这样的做法。应当为补丁应用（如Oracle 补丁集更新(PSU)）预定一个时间计划并且必须让租户知道这一计划。话虽如此，还是应作好应用一次性补丁的准备，但是必须对这些补丁对相应CDB 中所有租户的影响进行评估。
如果只有一个或少数几个应用程序(PDB) 需要紧急应用一次性补丁，则最高效的补丁应用方法是创建一个包含这些额外补丁的新的CDB，然后使用拔出/插入操作将这些PDB 逐个迁移到该CDB 中。注意这会增加需要管理的组件数量，不过这在短期内可能是可以承受的。
安全性
在任何整合环境中采用“最低权限”方法都将为加强安全性提供最大助益。在大多数情况下，单个Oracle Home 将托管相应节点中运行的所有数据库。这意味着，任何操作系统用户，只要是该Oracle Home 的DBA 组的成员，就都拥有对该主目录中运行的所有数据库实例的SYSDBA 访问权限。从易于管理的角度来讲这是个不错的方法，但这确实会引发安全性问题。
我们建议实施以下最佳实践：
?尽量降低对数据库服务器的访问权限。只允许SQL*Net pipe 访问。
?为所有DBA 创建具名用户账户，对特权命令提供sudo 访问权限
?为跨多个PDB 的管理任务创建通用用户
o 除了为运行管理任务而需要的对象（如一些过程）之外，
通用用户不应拥有任何其他对象。
?使用角色来限制特权；保持对SYSDBA 和SYSOPER 的有限的访问权限。
Oracle Database 12c 为备份管理、Oracle Data Guard 管理和加密密钥管理提
供了额外的管理角色，这些角色分别是：SYSBACKUP、SYSDG 和
SYSKM。您可酌情使用这些角色。
?启用Oracle Database Vault 以提供角色分离并控制数据访问
o可以对E-Business Suite、Siebel 和PeopleSoft 使用预先定义的数据领域。
o对静态数据进行加密
数据库整合
在数据库整合方式下，各个数据库整合到聚集在一个云池中的物理服务器上。该池中的任何服务器均可托管一个或多个Oracle 数据库实例。
通过使用Oracle RAC 或Oracle RAC One Node，这些数据库会继承服务器冗余带来的高可用性。通过向池中添加更多服务器或者向给定节点或实例添加更多CPU、内存或I/O 卡，可以实现弹性和可伸缩性。
尽管标准化十分重要，但确实需要容许例外情况，这样，添加更大（更高容量）的节点，
以及组成异构集群（从节点的CPU 或内存配置角度）也都是可行的。
故障隔离
这种整合方式的粒度是数据库。每个数据库及其相关实例都与同一池中的其他数据库相隔离。某个给定实例上发生的故障一般局限于该实例本身，即使这些数据库可能运行于同一Oracle Home 中。但是，可能会出现这样一些状况：因单个实例无响应而可能导致影响多个实例的结果；典型的需要节点重启的状况。通过应用程序设计和实施最佳实践可以限制实例或节点故障的影响。例如，通过使用动态数据库服务和连接池，并结合使用快速应用程序通知(FAN) 功能，应用程序能够更快速地响应中断事件，从而限制了这些事件的影响。
资源隔离
资源隔离处理系统资源的分配和分离。在数据库整合方式下，争用的资源包括CPU、内存
和I/O（存储容量以及IOP）。
?内存—在每个实例的基础上设置合适的MEMORY_TARGET 和MEMORY_MAX_TARGET 值，注意这些值必须对同一数据库的所有实例保持一致。
MEMORY_TARGET 不会对PGA 值强加硬性限制。强烈建议不要过量使用内存资
源。在Exadata 硬件上：
o OLTP：CDB 的(SGA_TARGET + PGA_AGGREGATE_TARGET) 总数+ 4 MB *（最大进程数）< 每个数据库节点的物理内存
o DW：CDB 的(SGA_TARGET + 3 * PGA_AGGREGATE_TARGET) 总数< 每个数据库节点的物理内存
?CPU —通过使用CPU_COUNT 或启用实例囚笼5设置合适的值。
建议采用后一种方法，因为通过使用实例囚笼可强制实施某种Database Resource
Manager (DBRM) 资源计划，从而能够更多地掌控CPU 使用量。
5 有关实例囚笼的详细信息，请参阅本文中标题为“云池设计”的一节
运营隔离
运营隔离确保对一个数据库或其运行环境执行的管理或维护操作不会影响同一云池中正在运行的其他数据库。这些活动包括启动和关闭实例、修补以及备份或恢复操作。
启动/关闭
通常只使用一个或最少数量的Oracle Home 来托管所有整合数据库。应为每位云DBA 创建具名用户，然后将这些用户添加到数据库口令文件（必须将REMOTE_LOGIN_PASSWORDFILE 设置为EXCLUSIVE）。这些具名用户于是被授予了SYSDBA 角色。通过为每个数据库使用不同的口令文件，即可保证用户只能获得自己管理的数据库的SYSDBA 权限。
打补丁
与PDB 整合方式相同，在整合环境中对数据库进行修补涉及两项任务：规划补丁应用以及实际应用补丁。应预先树立这样的见识：一次性或非计划的修补工作效率不高，因此不应鼓励这样的做法。应当为补丁应用（如Oracle 补丁集更新(PSU)）预定一个时间计划并且必须让租户知道这一计划。话虽如此，还是应作好应用一次性补丁的准备，但是必须对这些补丁对整个数据库的影响进行评估。
最高效的修补方法是克隆Oracle Home 目录，应用补丁，然后将数据库实例切换到新的主目录。而在RAC 环境中，如果提供了滚动补丁，则应使用它们来进行滚动修补。
安全隔离
同见PDB 整合一节讨论的内容。
整合多个CDB
在数据库一级，上文所述的数据库负载整合与大小设置原则同样适用于将多个CDB 和专用数据库整合到共享云池上的情形。不过，您必须根据每个CDB 中包含的PDB 的数量，以及要整合到云池上的CDB 与专用数据库的混合情况，来增加服务器和操作系统大小设置原则。
选择将哪些数据库整合到一起的一般性原则主要取决于您与数据库云租户达成的服务级别协议(SLA)。在基础架构一级，总而言之，要将这些SLA 与最适合实现这些SLA 的云池相
对应。这些云池本身则应使用标准化硬件和软件组件来构建并且应为它们设置合适的大小，以便支持预先确定的整合密度和隔离策略。
例如，图7 所示为一个数据库云部署，这里某个云池中的一组服务器划分为了三个服务器池，分别托管三个通过策略管理的6 CDB。在本例中，每个CDB 可代表一个使用不同的字符集，处于不同的补丁级别，或者属于不同的业务线之类的数据库。
图7. 利用Oracle Database 12c 进行数据库整合
在进行CDB 整合时，我们建议您预先确定针对每个数据库的策略并在提供服务时执行这些策略。
?每个CDB 拥有最大数量的PDB
?确定每个云池托管的CDB 和/或专用数据库的最大数量
在部署过程中严格执行这些策略将会为您带来均匀一致的环境。这样的环境将有利于实现
更轻松的自动化和生命周期管理。
6 通过策略管理的部署以服务器池为基础，这种情况下，在一个服务器池中运行的数据库服务将作为跨该服务器池中所有服务器的单一对象或统一体来运行。数据库部署于一个或多个服务器池中，服务器池的大小决定了相应部署中数据库实例的数量。
模式整合
在这种整合方式下，整合的数据库包含跨云池中一个或多个实例而运行的一个或多个应用程序模式。已实施此方法的客户往往将应用程序（模式）的数量限制为少于20。这种方式下租户的粒度是模式。
故障隔离
一个模式中的应用程序故障不会影响其他模式中的应用程序。登录风暴或不合适的中间层配置可能影响多个应用程序。为了限制这种影响，使用配置合适的中间层连接池是十分重要的。编写不良的数据库驻留代码（如PL/SQL）可能影响其他不相关的应用程序。因而在开发过程中必须进行严格的代码检查，在应用程序部署之前必须进行彻底的测试。
资源隔离
对于模式整合来说，资源管理是一项必要的工作。Oracle Database Resource Profile Limits 为限制资源使用提供了一个基本方法。通过设置资源限制，可以防止用户执行令系统繁忙的操作并防止其他用户执行操作。注意您还可以使用资源限制来加强安全性，确保用户退出系统后会话不会长期留置于连接状态。Database Resource Manager (DBRM) 和QoS Management 提供了对Resource Profile 的补充。
可以将应用程序分组到不同的用户组中，这些用户组采用相应的DBRM 资源计划指令。资源计划控制分配给用户组的CPU、I/O（在Exadata 部署中）和并行服务器进程资源。
对存储使用的控制则可以通过使用表空间配额来进行。
运营隔离
在模式整合方式下，尽量减少恢复和还原操作的影响是运营隔离的一个主要目标，补丁应用管理也是如此。
为了实现尽可能最高效的数据恢复，必须仔细设计备份策略。备份方法应该包含对应用程序来说恰当的恢复粒度。典型的方法是对各个模式进行夜间备份和Data Pump 导出。利用闪回方法（表、查询或事务级闪回）可以恢复已丢失或删除的数据，这种恢复过程具有最低的侵入性。如果数据已从闪回区域老化掉，则还可以使用恢复表包来帮助恢复丢失的数据。
修补方法类同于其他整合方式中讨论的方法。
安全隔离
模式间的安全隔离是模式整合最重要的一个方面。可以使用Oracle 数据库配置文件来限制对数据的访问，但是大多数情况下必须制定更严格的安全措施和策略。始终保护静态数据（通过加密技术），提供细粒度访问控制以及实施安全审计。这些实践活动意味着需要使
用透明数据加密、Database Vault 领域，以及用于运行时审计管理的Oracle Audit Vault and Database Firewall。
此外，还应实施以下最佳实践：
?限制SYSDBA、SYSOPER 及SYSASM 访问权限。根据需要利用SYSBACKUP 和SYSDG 角色。
?确保使用专用同义词。避免使用公共同义词。
?必须使用强数据库口令，并为PASSWORD_LOCK_TIME和
FAILED_LOGIN_ATTEMPTS 设置适当的值。
云池设计
云池的初始大小将取决于其托管的应用程序的类型以及这些应用程序各自的容量要求。大多数情况下，私有云将由一些较小的云池组成，而不会只是一个池。
云池应符合以下需求：
?业务需求
o为各个业务线或部门构建独立的云池
o为不同的SLA、合规性要求，或测试与开发构建独立的云池?功能需求
o为具有类似功能的应用程序构建一个云池。例如，分别为内部应用程序和外部应用程序构建一个云池
?技术需求
o根据操作系统类型、数据库版本或隔离需求构建独立的云池。
o考虑各种负载之间的互补性
云池常常使用特定的配置来构建并且支持特定的业务需求。最佳的做法是，将具有类似SLA 需求的应用程序共置于一个整合环境中，而将关键应用程序与非关键应用程序混置于同一个云池中则一般是不合适的。
可整合的应用程序数量取决于将要整合的应用程序的大小、资源使用量和SLA。此外，应设置预定义的系统资源使用量阈值，这将决定云池的容量。
建议使用标准模块化构建块构建云池。许多客户都选择基于四节点集群实现标准化，因为这为服务布置和应用程序负载增长提供了灵活性，并且通过为计划中断和组件故障防范提供更多选择而提高了可用性。
下面介绍对物理资源的配置：
CPU
最初确定CPU 的大小时，要确定将托管哪些应用程序，并且要留有一些余地，包括10% 的运营任务开销（如备份或调度任务等），以及用于负载故障切换的15% 的开销。云池中的工作节点保持在75% 的CPU 容量内，这样可以在一般使用量与余量之间达到良好的平衡。