Oracle数据库Multitenant新特性介绍

1、Oracle Multitenant：新特性介绍Oracle Database 12c 第 2 版 (12.2) PAGE 22 | ORACLE MULTITENANT：ORACLE DATABASE 12C 第 2 版中的新特性目 录 HYPERLINK l _TOC_250043 Oracle 云现在提供 Oracle Database 12c 第 2 版1 HYPERLINK l _TOC_250042 规模经济，隔离性和敏捷性，两者兼收并蓄5 HYPERLINK l _TOC_250041 中的 Oracle Multitenant6 HYPERLINK l _TOC_250040

2、整合6 HYPERLINK l _TOC_250039 开发和测试7 HYPERLINK l _TOC_250038 软件即服务7 HYPERLINK l _TOC_250037 中的新特性7 HYPERLINK l _TOC_250036 克隆 PDB8 HYPERLINK l _TOC_250035 可刷新 PDB9 HYPERLINK l _TOC_250034 PDB 重定位10 HYPERLINK l _TOC_250033 PDB 重定位的局限性12 HYPERLINK l _TOC_250032 拔出/插入增强13 HYPERLINK l _TOC_250031 迁移加密密钥13

3、 HYPERLINK l _TOC_250030 采用自动登录钱包的自助式供应13 HYPERLINK l _TOC_250029 PDB 归档13 HYPERLINK l _TOC_250028 何时使用 PDB 重定位，何时使用拔出/插入14 HYPERLINK l _TOC_250027 克隆增强14子集克隆和仅元数据克隆14快照克隆15 HYPERLINK l _TOC_250026 基于存储的快照15 HYPERLINK l _TOC_250025 基于文件系统的快照，由稀疏性启用16 HYPERLINK l _TOC_250024 Exadata 存储上的 ASM16 HYPERL

4、INK l _TOC_250023 本地撤消16 HYPERLINK l _TOC_250022 支持规模发展 消除整合障碍17 HYPERLINK l _TOC_250021 闪回 PDB17 HYPERLINK l _TOC_250020 PDB 级字符集17 HYPERLINK l _TOC_250019 每个 CDB 可包含 4k 个 PDB18 HYPERLINK l _TOC_250018 PDB 级自动负载信息库 (AWR) 数据18 HYPERLINK l _TOC_250017 热图18 HYPERLINK l _TOC_250016 隔离18 HYPERLINK l _TO

5、C_250015 资源管理19 HYPERLINK l _TOC_250014 内存管理19 HYPERLINK l _TOC_250013 商用存储上的 I/O 管理20 HYPERLINK l _TOC_250012 CPU 管理20 HYPERLINK l _TOC_250011 系统访问21 HYPERLINK l _TOC_250010 文件访问21 HYPERLINK l _TOC_250009 锁定配置文件21 HYPERLINK l _TOC_250008 Data Guard Broker 增强22 HYPERLINK l _TOC_250007 软件即服务23 HYPERL

6、INK l _TOC_250006 中 Multitenant 对 SaaS 的支持24 HYPERLINK l _TOC_250005 中 Multitenant 对 SaaS 的支持25 HYPERLINK l _TOC_250004 应用程序维护26 HYPERLINK l _TOC_250003 跨租户聚合27 HYPERLINK l _TOC_250002 应用程序容器 评价28 HYPERLINK l _TOC_250001 SaaS 解决方案需求回顾28 HYPERLINK l _TOC_250000 总结29规模经济，隔离性和敏捷性，两者兼收并蓄这不仅仅是规模。规模本身可视作一

7、种负面因素。随着组织的办公规模扩大，不只在一处办公，通信交流会变得更加困难，会需要更多的管理层级。这种情况下，组织愈加难以做到灵活敏捷，想一想，这就好像让一艘油轮笨拙地调头转向。这些问题表现为成本会随着规模的扩大呈指数级 增长。利用先进的自动化，第一代云带来的技术可以将这种成本模型改进为一种近乎线性的函数。下面我们以开发环境为例。要支持十位开发人员，您可能需要十个虚拟机 (VM)。要支持二十位开发人员，将需要 20 个VM。每个 VM 都存在固有的成本，即便它不承担任何大的负载也是如此。因此，成本与规模之间是一种线性关系。不过，这仍是朝着正确方向发展的重要一步。Oracle Multitena

8、nt 是面向下一代数据库云的架构。这种多租户架构彻底改变了上述状况。它实现了真正的规模经济。一个 VM 包含一个数据库，这种昂贵的模型被可插拔数据库 (PDB) 所取代。由于 PDB 固有的成本可以忽略不计，因此每位开发人员的 PDB 成本缩减为他们所做的实际工作。所有开发人员的 PDB 可整合到一个多租户容器数据库 (CDB) 中，运行该 CDB 的成本可以由这些开发人员共同分担。从计算资源角度讲，这是因为只有一组后台进程和一个共享内存区域 (SGA)。从管理角度讲，只有一个 CDB 需要进行备份、配置（以实现高可用性）以及修补等等。如果这种整合以牺牲隔离性和敏捷性为代价，那么通过整合实现规

9、模经济就没有很大的用武之地。在 Oracle Database 12c 第 2 版 (12.2) 的多租户架构中，我们在一套已有的强大隔离功能的基础上构建了一个全面的模型，该模型通过简单的配置即可为特定的用例提供正好合适的隔离级别。凭借强大的隔离功能，整合的各项负载不会互相干扰，因此大规模整合变成了现实。油轮调头转向这一比喻所传达的意思是，整合可造成笨拙的后果，而敏捷性，则可避免这种笨拙性，从而增进积极的方面。规模可通过巨大的购买力减少单位成本，但如果规模以牺牲敏捷性为代价，这些收益就会被抵消。在数据库方面，敏捷性指的是创建、克隆（甚至销毁）数据库的速度和效率。 还指的是能够在服务器之间、数据

10、中心之间、数据中心与云之间以及在云内移动数据库。出现这些情况的原因有很多：设备报废，被云资源替代；负载平衡；更改服务级别或处理峰值负载等等。这些是现代企业必须具备的能力，而 Multitenant 先进的功能可以使它们畅通无阻。规模经济的一个要点是，如果节省超过规模成本，则会实现真正的投资回报。Multitenant 的优势在于，其规模经济如此之大，以至于远比使用其他模型更容易实现投资回报。Multitenant 实现了真正的规模经济， 两者密不可分。Multitenant 不仅实现了规模经济，还实现了隔离性和敏捷性。中的 Oracle Multitenant对于 Oracle Multite

11、nant，我们处于这样一种瞻前顾后、左右为难的境地：该产品的早前版本具有完善的功能，然而新版本中又有大量新的功能。在深入探讨其中一些新功能之前，我们先简要概述一下 Oracle Database 12c 第 1 版 (12.1) 中的现有多租户架构及其主要优势。使用 Oracle Multitenant，可以将多个可插拔数据库 (PDB) 整合到单个多租户容器数据库 (CDB)。可插拔数据库是一个完备的功能齐全的 Oracle 数据库。从应用程序角度来看，它没有什么变化，这一点非常重要，因为这意味着，无需进行任何应用程序更改即可采用此架构。因此，从应用程序角度来看，PDB 就是数据库。但是，从

12、运营角度看，CDB 才是数据库。CDB 代表了单个整合运营环境。 这里只有一组后台进程和一个共享内存区域 (SGA)，由 CDB 中的所有PDB 共享。该架构消除了重复开销，从而能够充分利用可用资源。这意味着，您可以极大地减少资本支出 (CapEx)， 因为可以在每个服务器上整合更多的应用程序。从运营角度讲，您可以集中管理所有这些整合的 PDB，从而可以极大减少运营支出 (OpEx)。这对于备份、高可用性配置、补丁应用和升级等事项都适用。这些 CapEx 和 OpEx 上的减少是Multitenant 实现我们云计算承诺的一部分。该架构特别适合于以下三个主要用例：整合几年前，人们重点考虑的是服

13、务器（以及在其上运行的软件）是否能够扩展以承担负载。如今，Oracle Exadata 数据库云平台，实际上还有我们的云环境（包含许多 Exadata 之类的设备），诸如此类的现代融合基础架构提供了强大的能力，这种情况下，人们开始听到收缩一词。也就是说，即便是重要的应用程序，通常也很可能可以将多个应用程序 整合到单个服务器中。要实现规模经济，关键是要能够收缩这些服务器以便高效地支持各种负载，而不会过度供应， 但同时始终要将隔离性放在首位，为了隔离而独立地运行各种负载。Multitenant 凭借 PDB 的内在隔离性，非常适用于这一情形。Resource Manager 与此完美集成，支持通过

14、定义简单而强大的策略来控制 PDB 之间的资源分配。在 12.1 中，至多可以将 252 个可插拔数据库整合到单个多租户容器数据库中。每个 CDB 包含 252 个 PDB，这已经很多了！开发和测试敏捷性，是现代开发和测试等组织所必须具备的，是云计算的另一个重要特点。在将多个数据库作为一个进行管理的同时，我们适当地保留了细粒度的控制，因此可以提高敏捷性。PDB 的供应极其快速、简单，且能够很好地融合到自助式供应界面 这是数据库即服务 (DBaaS) 的一个重要特点。PDB 的供应通过克隆过程来完成，克隆有多种类型，包括完全克隆、子集克隆，甚至还有快照克隆的精简供应（利用写时复制技术）。可插拔数

15、据库是一种可移植数据库 通过拔出/插入过程可以非常简单快速地在服务器之间移动 PDB。这可以用于负载平衡以及迁入/迁出云等事项。与 Oracle Real Application Clusters (RAC) 无缝集成后，能够将一个 PDB 关联到集群中的一个特定节点，或者让其在多个节点间一致运行，于是我们能够灵活地进行调整以适应不断变化的负载。该功能，以及刚刚提到的简单自助式供应，是数据库云的其他重要特点。软件即服务软件即服务 (SaaS) 是云计算的一个经典示例，相应地，也是 Oracle Multitenant 的一个经典用例。Multitenant 为我们可能描述为士气低落的千禧时代应

16、用程序供应商的应用程序提供了一种即时的 SaaS 架构。这些应用程序通常功能非常丰富，但是其架构旨在支持过时的独立内部部署模型，即使它们功能卓越，也无法与现代 SaaS 架构相比。Multitenant 明显改变了这一格局。它让每个租户可以独立存在于一个 PDB 内与其他租户隔离，但又让多个租户可以整合存在于同一个 CDB 内，从而让这些应用程序能够容易地以 SaaS 配置重新部署，而无需进行任何更改！中的新特性在上述版本的极其坚实的基础上，我们开发了 Oracle Database 12c 第 2 版 (12.2) 这一新版本中提供的所有新功能。新版本对上述三个方面都进行了重要增强。本白皮书

17、的余下部分将专门介绍这些各种增强。有关 12.1 中的 Oracle Multitenant 的更详细的信息，建议读者阅读 12.1 中的 Oracle Multitenant 白皮书 (2013)。供应增强数据库供应历来就是令数据库管理员 (DBA) 头疼的事情。现代组织在无止尽的压力下需要不断地创新，因而不断要求开发团队交付新的系统以提供现代客户所需功能，包括移动功能、社交交互和随处可用的云。同时还需要遵守法规要求以及严格的安全性，后者是在这个网络黑客攻击无处不在的当代环境中生存的一项基本技能。除了所有这些要求之外， 还需满足更高层面的要求，即可伸缩性、可用性、性能、可管理性和生产力方面的

18、基本技术要求，而这些历来就是Oracle 数据库卓而不群的优势。以持续开发、持续集成、持续交付为特点的DevOps这一现代趋势加重了这一压力，因为 Oracle 数据库是具备所有上述特点的开发环境的基础层。如前所述，12.1 中的 Oracle Multitenant 明显改变了这一状况。使用 Multitenant 供应新数据库十分简单，只需克隆 PDB 即可。融入现代 DBaaS 模型后，数据库供应流程变得快速简单，过去可能需要数天或数周（有时甚至数月），并需要多个团队的人员参与其中，而现在只需数分钟甚至数秒，可通过简单的自助式界面来执行。 在 12.2 中，我们对这些基本的供应操作进行了

19、大的增强，使它们可以联机执行。克隆 PDB在 12.1 中，要克隆 PDB，源 PDB 必须在克隆操作期间处于静止状态。用通俗的话来说，我们称之为冷克隆操作，因为它需要源数据库停机（从事务角度讲）。热克隆更可取，这说起来简单，但做起来并不容易！然而，在 12.2 中，我们支持热克隆。在 Oracle 数据库支持的所有存储上都可以使用这种联机克隆功能。当源 PDB 仍以读写方式打开时，可以进行热克隆。这意味着，无需中断源 PDB 中的操作即可进行热克隆。热克隆无需应用程序停机。下面我们从技术上简要阐述热克隆过程中幕后发生的事情。如果读者感兴趣，可以了解一下。若对这些细节不感兴趣， 可以跳到下一节

20、可刷新 PDB。从技术上讲，我们在热克隆过程中做的事情称为对源 PDB 的数据文件中所有块的模糊读取。这里的意思是，如果克隆操作在时间 t0 开始，到读取源 PDB 中的最后一个块并将其复制到目标时（时间 t1），可能对已经复制的一些块进行了一些更改。那么，在此阶段，克隆可能与源在物理上不一致。下一步是复制时间 t0 与 t1 之间对源 PDB 积累的所有重做，并将其传输至目标。然后将该重做应用于目标 PDB。在此阶段，目标 PDB 将成为截至时间 t1 源 PDB 的精确物理副本。但是，这既包括已提交的事务，也包括未提交的事务， 因此应认为可能在事务上是不一致的。现在需要的是回滚未提交的事务

21、。为此，要对所有这些未提交的事务应用撤消。这是克隆操作的最后一个阶段。得到的克隆将是截至时间 t1 源 PDB 的事务一致副本。也就是说，截至时间 t1，源 PDB 中的所有已提交事务将出现在克隆中，所有未提交的事务将回滚。由此可见，实现热克隆功能的关键是本地撤消。Oracle Multitenant 的这个新特性将在本文的其他章节进行介绍。为了执行热克隆，还须启用归档日志记录。所有这些在以下熟悉的克隆操作中以原子 方式执行。create pluggable database target from source;只有熟悉 12.1 功能的客户才需要了解热克隆与冷克隆之间的区别。自 12.2

22、起，我们将直接称为克隆（所有克隆都是热克隆）。可刷新 PDB可刷新 PDB 功能建立在热克隆的基础之上。这里的一个经典用例是开发和测试，在此用例中，我们需要生产 PDB 的副本。生产数据库往往很大。它们越大，复制所需的时间就越长。要对数十 TB 规模的生产数据库进行复制，可能需要数天的时间。经常做这种事情是不可取的，因此这种生产数据库的开发副本往往随着时间的推移而变得相当陈旧。数据库越陈旧，对于开发用途（例如调试）就越发不相关。可刷新 PDB 功能则可消除这一问题。第一步是对源数据库进行完全克隆。这一步按实际所需的时间执行 数小时、数天等等。要知道，现在我们有了热克隆功能，该克隆无论花多长时间

23、都没有关系，因为源数据库无需任何停机。当初始克隆完成后，数据库即可供人们使用了。可刷新 PDB 的预期用例是作为黄金主数据库。也就是源数据库，各位开发人员从该数据库进行克隆 通常是极为高效的快照克隆（甚至对于超大型数据库，数秒或数分钟内也可创建完成）。快照克隆在其他 Oracle 白皮书中进行了介绍。作为黄金主数据库，这个可刷新 PDB 在刷新之间应始终以只读方式打开。该 PDB 必须在刷新操作过程中关闭。现在，当克隆变得陈旧时，我们可以对其刷新。为此，我们应用自上次刷新以来积累的所有重做。即使源数据库非常庞大，增量重做通常也将小得多。因此，该过程将远远快于初始热克隆。使用从生产数据库复制的新

24、数据刷新生产克隆也将简单得多。可刷新 PDB 可以定义为自动刷新（按特定的时间计划刷新）或手动刷新（按需刷新）。 也可以对定义为自动刷新的PDB 执行按需刷新。可以将定义为自动刷新的 PDB 转换为手动刷新，反之亦然。要创建自动刷新的 PDB，语法为create pluggable database Golden_Master_PDB from Prod_PDBDBLinkrefresh mode every 360; - (360 minutes)随后，该可刷新 PDB 应以只读方式打开，如下所示：alter pluggable database Golden_Master_PDB read

25、 only;要创建手动刷新的 PDB，语法为：create pluggable database Golden_Master_PDB from Prod_PDBDBLinkrefresh mode manual;如前所述，当初始克隆操作完成后，可刷新 PDB 可以只读方式打开。后续刷新操作需要关闭 PDB，可以通过以下语句来实现：alter pluggable database Golden_Master_PDB refresh;注意：如 12.1 中的 Multitenant 白皮书 (2013) 所述，当 PDB 在创建后首次以读写方式打开时会执行重要步骤。通常情况下，可将这个首次以读写方

26、式打开 的操作视为完成 PDB 创建的一个重要步骤。需要注意的是，这不适用于可刷新PDB。事实上，不以读写方式打开可刷新 PDB 非常重要，因为它有可能以后不再刷新。PDB 重定位可插拔数据库是一个完备的功能齐全的 Oracle 数据库。它们是可移植的数据库，因此称为可插拔。12.1 实现了这种可移植性，只需将 PDB 从一个 CDB 中拔出，再插入到另一个 CDB 中。这是一个非常强大的功能。它使 PDB 成为了通往云的理想媒介；客户只需将其 PDB 从其数据中心内部服务器中的 CDB 中拔出，然后插入到 Oracle 数据库云服务，或者也可以插入到客户资产中的其他服务器，即可实现这一目标。

27、拔出/插入也是执行负载平衡的一种简单方法， 通过将 PDB 从负载沉重的服务器移至具有更多可用容量的服务器，即可实现负载平衡。但是，使用拔出/插入方法在 CDB 之间移动 PDB 需要在拔出/插入操作过程中停机。当在具有共享存储的服务器之间移动时（例如，在云环境中移动 PDB 以进行负载平衡时常常就是这样的情况），该停机时间会非常短，因为这只是一个元数据操作，无需物理上移动数据文件本身。但是，在数据中心之间移动数据库，或者从地面移至云（或者反之） 时，适用的是物理法则 所有数据都必须物理移动。对于大型数据库，该过程可能需要相当长的时间，具体取决于底层网络的能力。相关的停机可能产生问题。服务级别

28、协议 (SLA) 通常包含两个相互矛盾的方面 性能和可用性。如果数据库存在违反其性能 SLA 的危险，通常的解决方案是将其移至具有更多可用处理能力的服务器。但是，这样做往往需要应用程序停机，而这可能违反 SLA 的可用性要求。PDB 重定位是在 CDB 之间移动 PDB 的新方法。该方法在 12.2 中引入，旨在让 Oracle 数据库云服务可同时满足与客户达成的性能和可用性 SLA 要求。由于 Oracle 数据库云服务基于我们客户所使用的完全相同的数据库技术而构建，因此我们的客户一般也可以使用该功能。其目标是完全避免停机。下面提供有关 PDB 重定位的一些更详细的信息。如果读者认为这些信息

29、无关紧要，可以跳到下一节。从技术上讲，PDB 重定位构建于可刷新 PDB之上，我们已经了解到，可刷新 PDB 又构建于热克隆之上。当需要到独立的监听器时，也可能需要透明的连接转发。在操作上，PDB 重定位分为两个步骤完成，如下所示：将 PDB 重定位到新服务器在新位置打开 PDB第 1 步需要将 PDB 从其原始位置克隆到所需的新位置。换句话说，在这一步完成的那一刻，这个 PDB 将有两个事务上一致的副本，一个位于源服务器，一个位于目标服务器。在该操作期间，处理会继续在原始位置的数据库上无间断地进行。连接到该数据库的应用程序的用户不会察觉到正在执行重定位。从技术上讲，这与上述可刷新 PDB 的

30、创建基本相同。所有现有的应用程序连接，以及这一步执行过程中建立的新连接，都会继续连接至其原始位置的 PDB。正如我们已了解到的，如果第 1 步在时间 t0 开始，于时间 t1 完成，那么在时间 t1，两个 PDB 的内容将是事务一致的。随着处理继续进行，在连接切换至新位置之前，需要考虑超过时间 t1 后原始位置 PDB 中可能发生的数据变化。第 2 步是完成重定位。同样，这一步在很大程度上对于应用程序用户是透明的，虽然操作结束时，与 PDB 的连接从其原始位置切换到了新位置。这一步的一个重要事情是确保原始位置的 PDB 中的所有已提交事务都保存到了目标位置中。从技术上讲，正如我们已知道的，在处

31、理继续在新位置执行之前，我们需要考虑在时间 t1 后提交至源位置 PDB 中的任何事务。从高层面上说，所有事务处理必须先在源位置的 PDB 中停止，我们可以将这一时刻标记为时间 t2。我们必须将在源位置的 PDB 中积累的所有已提交事务重新应用到目标位置，事务处理才可在新位置继续进行。基于这些要求， 这个打开阶段包含以下子步骤。2a.以只读方式打开。我们知道，截至时间 t1，新位置的 PDB 在事务上是一致的，因此可以安全地以只读方式打开。这样，它在新位置可以立即用于查询，同时尝试 DML 的连接将启动。尽管在此阶段一些已提交的事务有可能在目标位置不可见，但它们不会丢失（我们将看到这点）。在时

32、间 t1，对目标位置中的 PDB 执行的任何查询（在此阶段只允许查询）的行为，就好像对源位置中的 PDB 执行一样，没有任何不同。这可以视为读取一致性的特殊情况。2b.连接转发。所有连接都必须从源位置排出，然后在目标位置重新建立。新连接请求将转发至目标位置并与该位置的PDB 建立连接。精心设计的现代应用程序通常通过连接池与底层数据库进行交互，连接池可以通过少量的（计算资源开销相对较高的）数据库连接支持大量的应用程序用户。当事务完成，这些连接释放到连接池时，连接关闭。运行时间较长的事务或编写不良的应用程序可能会导致连接不能及时、自然地释放。短暂间隔后，这些连接自动终止，并在目标位置重新建立。该过

33、程以增量方式执行，以避免在目标位置出现登录风暴。这意味着，在 PDB 重定位过程中，一些事务可能会中断。请注意，这与 PDB 的总体可用性近乎持续的描述并不矛盾。出于这一原因，管理员需要注意这些长时间运行事务的处理时窗，以尽可能地减少 PDB 重定位的影响。具体的连接转发取决于 PDB 源位置和目标位置的监听器配置。存在三种可能性：2.b.i. 共享监听器。这种情况通常涉及到在同一个服务器中的 CDB 之间进行重定位，例如，将 PDB 重定位到安装了一组不同选件的 CDB 时就适合这种情况。在这种情况下，会在新位置将 PDB 重新注册到该监听器。.交叉注册的监听器。这是在一个数据中心内的服务器

34、之间进行重定位（可能出于负载平衡目的）的典型情形。在这种情况下，会在新位置将 PDB 重新注册到两个监听器。.没有交叉注册的独立监听器。在数据中心之间重定位 PDB 时通常是这种情况；可能是从客户的内部数据中心重定位到 Oracle 数据库云服务。由于没有交叉注册，这种情况较为复杂，因为事实上目标位置的监听器不知道源 CDB， 反之亦然。在这种情况下，我们提供了两个可用性级别：高可用性和最高可用性。高可用性恰如其名，因为 PDB 确实是在新位置差不多立即用于直接连接的。高可用性 PDB 重定位的语法如下所示：create pluggable database My_PDB from My_PD

35、BDBLink availability high;该语句应从目标 CDB 发出。（高可用性为默认设置。）最高可用性更进一步，能够将与原始位置的 PDB 建立的连接自动转发到新位置。最高可用性 PDB 重定位的语法如下所示：create pluggable database My_PDB from My_PDBDBLink availability max;该语句应从目标 CDB 发出。现在，需要防范可能在原始位置使用与已重定位的 PDB 相同的名称创建另一个 PDB 的情况。如果允许发生这种情况，确实可能导致非常混乱的情况！为避免这种情况，当执行最高可用性 PDB 重定位时，我们在源 CDB

36、 中创建了一个墓碑。这是源 CDB 中一个元数据条目，可以通过从源 CDB 的根容器查询 v$containers 来查看。墓碑PDB 是可见的，具有已重定位状态。2c.在目标位置中应用增量事务。在时间 t1 与 t2 之间对源 PDB 积累的任何重做数据复制到目标并在此应用。在此阶段，目标 PDB 将是截至时间 t2 源 PDB 的精确副本。但是，这既包括已提交的事务，也包括未提交的事务。现在需要的是回滚未提交的事务。可以通过对所有这些未提交的事务应用撤消来实现此目标。由于我们已确保不会在原始位置发生任何事务，我们会看到目标现在已赶了上来。2d.以读写方式打开目标。现在从原始位置删除数据文件

37、。PDB 重定位现已完成。所有处理在 PDB 的新位置继续进行，就好像什么都没发生过，尽管如我们所见，发生了很多事情！不过，操作人员需要做的只是发出几个 SQL 语句。 不需要应用程序停机。 不需要更改任何应用程序。 不需要更改任何连接字符串。它就正常工作了。请注意，对于在没有交叉注册的独立监听器之间的 PDB 重定位情况，原始位置中墓碑PDB 的存在意味着，不能立即将 PDB 重定位回其原始容器，至少不会使用其原始名称（因为墓碑 PDB占用了该命名空间）。但是，要知道，这种情况预计不是永久性的。如上所述，最高可用性 PDB 重定位包括自动连接转发。这使得客户端能够继续连接到应用程序数据库，而

38、无需对连接字符串进行任何更改。不过，这的确涉及到一次额外的网络跳跃。希望在方便之时，可以对应用程序连接字符串进行更改，以提供与新位置中数据库的直接连接。此时，可以直接将墓碑 PDB 从原始位置删除。之后，将 PDB 重定位回其原始容器（如果需要）不会有任何障碍。PDB 重定位的局限性通常情况下，PDB 重定位会受到和拔出/插入相同的插入兼容性限制。该主题在 12.1 中的 Multitenant 白皮书 (2013) 中进行了详细介绍。实际上会通过对目标 CDB 评估 PDB 的 xml 清单文件来检查 PDB 的插入兼容性。然而，对于 PDB 重定位，不应通过执行拔出操作创建 xml 清单文

39、件（因为 PDB 重定位是一个联机操作）。而应通过连接至原始位置的PDB 并发出以下命令来生成清单文件execute DBMS_PDB.Describe() into PDB_manifest.xml;拔出/插入增强迁移加密密钥现代云部署应包含全面的安全战略，例如在 Oracle 高安全性架构中实施的战略，这在 Oracle 单独发布的文章中进行了介绍。我们的安全理念是，通过包括预防、检测和管理组件的全面的安全战略提供纵深防御。 没有任何单一的技术组件可以提供全面的保护；但是，Oracle 透明数据加密 (TDE) 提供了一个基本功能。在 Oracle 数据库云服务中，TDE 是必不可少的 我

40、们数据库云服务中的所有数据库都由 TDE 来保护。在我们接受混合云理念的客户中，有很多想像我们构建我们自己的云一样构建他们自己的云，这样的话，他们也需要实施 TDE。因此，需要一种方法在拔出/插入操作过程中在 CDB 之间迁移 PDB 级加密密钥。在 12.1 中，密钥的这种导出/导入与 PDB 拔出/插入操作分开完成。此过程在 12.1 中的 Multitenant 白皮书 (2013) 中进行了介绍。在 12.2 中，加密密钥的迁移通过与拔出/插入操作相集成而得到了简化。从技术上讲，加密密钥通过 xml 清单文件进行传输，在 xml 清单文件中它们通过共享密钥进行了加密。这是在拔出和插入语

41、句中使用一些额外的子句实现的，如下所示：拔出：以 SysDBA 身份在源 CDB 的根容器中执行：alter pluggable database MyPDB unplug into MyPDB_manifest.xmlencrypt using ;插入：以 SysDBA 身份在目标 CDB 的根容器中执行：create pluggable database MyPDB using MyPDB_manifest.xml decrypt using ;采用自动登录钱包的自助式供应数据库即服务 (DBaaS) 的一个重要特点是自助式供应。正如我们所看到的，Oracle Database 12c 的

42、容器数据库架构迄今是用于部署 DBaaS 的极为高效的模型。PDB 不仅是通往数据库云的媒介，而且是数据库云的推动者。正因如此，我们常常提到可插拔 数据库即服务或 PDBaaS。根据定义，PDBaaS 不适合基于口令的钱包，因为后者在设计时未考虑无人值守操作方式。出于这一原因，TDE 也可通过自动登录钱包来操作。这些内容在其他文章中有详细介绍，但为了了解 PDBaaS，这里有必要总结一下基本要求。这些操作，虽然在 12.1 中也支持，但在 12.2 中进行了简化。PDB 归档拔出/插入为在 CDB 之间移动 PDB 提供了一种简单、快速、高效的方法。拔出操作的基本语法是alter plugga

43、ble database MyPDB unplug into PDB_manifest.xml;其中，PDB_manifest.xml 称为 PDB 的xml 清单文件。当在无共享存储的 CDB 之间移动 PDB 时，有必要以物理方式将该 xml 清单文件以及 PDB 的所有数据文件复制到目标服务器。12.2 继续支持该语法。此外，还引入了一个新功能，即能够将清单文件和所有数据文件组合到一个文件中，称为 PDB 归档。这个 PDB 归档总是带有扩展名 .pdb，只需在熟悉的拔出语句中指定归档文件扩展名 (带有 .pdb)，即可实现归档，就像这样：alter pluggable database

44、 MyPDB unplug into MyPDB_archive.pdb;相应地，当以通用的 SysDBA 身份连接至目标 CDB 的根容器时，使用以下命令从其归档文件插入 PDB：create pluggable database MyPDB using MyPDB_archive.pdb;何时使用 PDB 重定位，何时使用拔出/插入拔出/插入在 12.2 中仍是一个非常强大的操作，不仅受到全面支持，甚至还有所增强。但是，如上所述，12.2 中引入的PDB 重定位功能提供了实现拔出/插入操作的另一种方法。PDB 重定位有个很大的优点，即它是一个联机操作，也就是说，PDB 迁移无需应用程序停机

45、。拔出/插入则不然。因此，预计大多数 CDB 之间的 PDB 迁移将使用 PDB 重定位来执行。但是，仍有少数情况宁愿使用拔出/插入方法。其中包括： 在具有不同的 Oracle 数据库版本或补丁级别的 CDB 之间移动 PDB 在安装了不同选件的 CDB 之间移动 PDB克隆增强借此白皮书发布之机会，我们列出自初始版本 12.1 以来引入的对 Multitenant 克隆的各种增强。子集克隆和仅元数据克隆有时，需要在创建克隆时包括 PDB 表空间的子集。该内容在其他文章中有详尽介绍，但实质上，这是通过使用 createpluggable database 语句中的 user_tablespac

46、es() 子句实现的，就像这样：create pluggable database NewPDB from OldPDB user_tablespaces(TS1, TS2);从技术上讲，其结果相当于使与任何排除模式相关联的数据文件保持脱机状态。与这些排除模式相关联的元数据仍位于PDB 字典中，可以通过发出drop user / cascade语句直接删除。从模式整合升级至 Oracle Multitenant 的客户发现该功能非常有用，因为一个典型的模型是每个模式具有专用表空间。例如 ， 一个数据库 中整合有三个 模式 Schema1 、 Schema2 和 Schema3 ， 这 些模式分

47、别使 用专用表空 间Schema1_TS、Schema2_TS 和 Schema3_TS，当从该数据库升级时，可以执行如下一系列操作升级到 Multitenant（我们假设这样一个起点：非 CDB 已经升级至 12.2）：- (In the non-CDB.) Create manifest file.execute DBMS_PDB.describe(non$cdbDBLink) into Non_CDB.xml;- (In CDB Root as a common SysDBA.) - Adopt multi-schema DB as a PDB. create pluggable dat

48、abase MultiSchema using Non_CDB.xml;alter pluggable database MultiSchema open;- (While connected to PDB MultiSchema.) Complete conversion of PDBs metadata.NonCDB_to_PDB.sql- (In CDB Root as a common SysDBA.) Create PDBs from schemas.create pluggable database PDB1 from MultiSchema user_tablespaces(TS

49、1); create pluggable database PDB2 from MultiSchema user_tablespaces(TS2); create pluggable database PDB3 from MultiSchema user_tablespaces(TS3);- Close and drop multi-schema PDB because it has now served its purpose.alter pluggable database MultiSchema close;drop pluggable database MultiSchema incl

50、uding datafiles;在这些步骤中，为每个模式创建了 PDB。接下来依次连接至每个 PDB，去除未使用模式的元数据。例如，连接至PDB1，发出以下语句：drop user Schema2 cascade;drop user Schema3 cascade;子集克隆的极端情况是仅元数据克隆。创建仅元数据克隆的语法是：create pluggable database DevPDB from ProdPDBDBLink no data;该功能可用于创建生产数据库的“快速而粗糙的”克隆，用于调试目的。快照克隆PDB 克隆的一种非常强大的变体是快照克隆。快照克隆的行为与源 PDB 的完整数据

51、集克隆一样，但增量存储消耗可忽略不计。由于创建快照克隆过程中需要物理写入的数据极少，因此创建过程极快。基本语法就是在标准克隆语法中添加snapshot copy 子句，例如：create pluggable database Snapshot_PDB from Source_PDB snapshot copy;快照克隆的概念在 12.1 中的 Multitenant 白皮书 (2013) 中进行了详尽描述，因此这里不再赘述。但是，借此白皮书发布之机，我们更新了支持快照克隆的存储技术列表。这些存储技术分为三类，每一类有不同的特点：基于存储的快照某些存储技术原生支持可高效利用存储的文件副本。Ora

52、cle Multitenant 可利用这些底层功能的全部能力，而无需额外增加一个不必要的专有层。我们将这些称为基于存储的快照，目前在以下平台上支持该功能： Oracle ZFS 存储系统 Oracle ASM 集群文件系统 (ACFS) NetApp EMC基于存储的快照的主要特点是，源 PDB 尽管是快照克隆的基础，但仍可读写。基于文件系统的快照，由稀疏性启用在某些情况下，数据库部署在简单文件系统上，而不是专用的存储技术。大多数现代文件系统都支持稀疏性。在这些情况下，通过在数据库创建过程中指定 CloneDB=TRUE，快照克隆仍然可行。在这些情况下，存在这样的限制，即在任何快照克隆的生命周

53、期，源 PDB 要保持只读状态且无变化。实际上，这一限制往往不是多么麻烦之事，因为快照克隆的典型用例往往总是需要只读克隆源： 可刷新 PDB 在开发和测试环境中用作黄金主数据库，本文其他章节对此进行了描述。 快照克隆的另一个常见应用是供应沙盒环境，以便进行破坏性假设分析。Exadata 存储上的 ASMExadata 存储上的 Oracle 自动存储管理 (ASM) 也支持创建 PDB 的快照克隆。不过，也存在这样的限制：在任何快照克隆的生命周期，源 PDB 要保持只读状态且无变化。随 Oracle Database 12c 第 2 版提供的 Exadata 存储软件也支持基于所谓分割镜像技术

54、的快照。Exadata 存储在 Oracle 发布的其他文章中进行了详尽的描述。不过，为了这里的讨论，在此说明一下，在 ASM 中，数据库的所有底层数据文件都分组到一个磁盘组中。在每个磁盘组中保留了文件的许多冗余副本即镜像。只需从文件 组中分割一个镜像，即可非常快速地创建 PDB 的一个克隆。当前单独的 PDB 所需的其他镜像在后台自动创建。本地撤消在 12.1 中，提供对整个 CDB 的全局撤消即共享撤消功能。使用共享撤消，在执行（冷）克隆或拔出等操作之前，数据库需要检查源 PDB 中是否有任何未提交的事务。这是为了避免克隆或插入操作后 PDB 中出现事务一致性方面的问题。（如果存在任何未提

55、交的事务存在，会发出以下错误：ORA-65126 可插拔数据库未完全关闭，存在需要恢复的活动事务。在这种情况下，需要以读写方式打开 PDB，然后等待直到 SMON 进程可以对它们进行清理。）在 12.2 中，我们引入了 PDB 级撤消即本地撤消功能。本地撤消避免了这些困难，因此显著提高了这些重要操作的可预测性。此外，它还支持 12.2 中 Multitenant 的许多主要新功能，其中包括： 热克隆 可刷新 PDB PDB 重定位 闪回 PDB共享撤消在 12.2 中仍受支持，但只是主要用于升级过渡型用途。可以说，执行 PDB 级撤消会有少量的技术和管理开销，但本地撤消带来的好处远远利大于弊（

56、支持本白皮书及其他文章中所述的所有新功能）。简单的规则通常就是极好的。如果在特定的情况下没有确实有力的理由来采用共享撤消，可以遵循一个很好很简单的规则：在所有情况下尽快转换为本地撤消。默认情况下，Database Configuration Assistant (DBCA) 创建新 CDB 时会启用本地撤消。撤消模式，无论是本地撤消还是共享撤消，都是整个 CDB 的一个要么全有要么全无的属性。而不存在一半这样一半那样的情况。要么对所有 PDB 启用本地撤消，要么对整个 CDB 启用共享撤消。可以在本地撤消与共享撤消之间来回切换。但是这样的转换需要重启 CDB。当将 PDB 从启用共享撤消的 C

57、DB 移至启用本地撤消的 CDB 时，会自动创建所需的本地撤消表空间。 当将 PDB 从启用本地撤消的 CDB 移至启用共享撤消的 CDB 时，会在首次以读写方式打开 PDB 时短暂使用本地撤消表空间来回滚未提交的事务。之后不再需要，可以删除。当 CDB 从共享撤消转换为本地撤消，或从本地撤消转换为共享撤消时，也是如此。Oracle Real Application Clusters (RAC) 集群中打开 PDB 的每个节点都需要一个本地撤消表空间。如果将 PDB 从 2 节点 RAC 移至 4 节点 RAC（并在所有节点中打开），会自动创建所需额外的撤消表空间。如果 PDB 重新移回，两个

58、撤消表空间将是多余的，可以删除。注意：无需将 CDB 级数据库参数 compatible 设置为 12.2 即可启用本地撤消。撤消模式（共享撤消或本地撤消）不被认为是插入兼容性问题。支持规模发展 消除整合障碍Multitenant 可以实现真正的规模经济，并且两者密不可分，关于这点我们已经讲了很多了。 您整合的越多，节省的就越多。因此，消除任何整合障碍非常重要。可以说，在 12.1 中，有几个 Oracle 数据库功能无法用于多租户架构。这些总的来说可以视作大规模整合的障碍。12.2 消除了这些障碍。本节将介绍在 12.2 中现在可以用于 Multitenant 的一些重要的 Oracle 数

59、据库功能。闪回 PDB现在完全支持闪回 PDB。PDB 级字符集在 12.2 中，Multitenant 支持整合使用不同字符集的 PDB。要求是对 CDB 配置 AL32UTF8。但是，现在，可以将使用不同字符集的 PDB 整合到单个 CDB 中。字符串在每个PDB 中进行适当处理。此外，当执行跨容器聚合时（可能使用 containers() SQL 结构），仍可适当处理来自这些不同PDB 的字符串。换句话说，不必再将非 CDB 转换为 AL32UTF8（使用 DMU），即可使用 Multitenant 整合它们。例如，我们有一个字符集为 AL32UTF8 的 CDB，可以将以下 PDB 整

60、合到该 CDB 中： 使用 Kanji 字符集的 PDB_Japan 使用 ISO8859_p1 字符集的 PDB_EMEA 以及任意数量的其他 PDB每个 CDB 可包含 4k 个 PDB在 12.1 中，每个 CDB 可包含 252 个 PDB，这个数量已经相当多了，但在 12.2 中，我们将该数量提高了 16 倍，增加到了 4,096 个（即 4k）。因此，使用 Multitenant，您整合的越多，节省的就越多这样的说法可不只是一句浮夸的口号。我们想要支持巨大的规模，以实现巨大的节省。这种规模对于典型的 SaaS 部署来说是现实的，而且是有经验可循的，依据的是我们在 Oracle 云中