CN108431810B

CN108431810B - 代理数据库

Info

Publication number: CN108431810B
Application number: CN201680075373.2A
Authority: CN
Inventors: T·巴比
Original assignee: Oracle International Corp
Current assignee: Oracle International Corp
Priority date: 2015-10-23
Filing date: 2016-10-21
Publication date: 2022-02-01
Anticipated expiration: 2036-10-21
Also published as: EP3365808B1; CN108431804B; EP3365807A1; CN108475271A; EP3365807B1; CN108475271B; EP3365808A1; US10628422B2; EP3365805A1; EP3365805B1; CN108431810A; US20170116278A1; CN108431804A

Abstract

在方法中，当容器数据库内的可插拔数据库被运输到新的容器数据库时，该可插拔数据库被替换为存储用于该可插拔数据库的转发信息的代理可插拔数据库。当接收到要在代理可插拔数据库上执行的命令时，处理该命令的数据库服务器使用存储在代理可插拔数据库内的转发信息将命令转发到负责新容器数据库的第二数据库接收器，以供在可插拔数据库上执行。然后执行命令的结果被返回到第一数据库服务器。因此，引用原始容器数据库内的可插拔数据库的应用代码不必被重写以引用新位置，并且对于可插拔数据库的实际位置能够保持透明。

Description

代理数据库

技术领域

本发明一般而言涉及用于建立驻留在容器数据库内并且将命令转发到驻留在不同容器数据库内的可插拔数据库的代理数据库的技术。本发明还涉及允许跨可插拔数据库对数据进行逻辑分区的容器映射的技术。本发明还涉及查询优化技术，其使查询协调器进程以及它的从进程之间以及不同远程容器数据库之间传送的数据量最小化。

背景技术

本部分中描述的方法是可以被追寻的方法，但不一定是先前已被构思或追寻的方法。因此，除非另外指出，否则不应当假定在本部分中描述的方法中的任何方法仅仅因为它被包括在本部分中就被认为是现有技术。

数据库系统

数据库管理系统(DBMS)管理数据库。DBMS可以包括一个或多个数据库服务器。数据库包括存储在持久性存储器机构(诸如一组硬盘)上的数据库数据和数据库字典。数据库数据可以存储在一个或多个数据容器中。每个容器包含记录。每条记录内的数据被组织到一个或多个字段中。在关系型DBMS中，数据容器被称为表，记录被称为行，并且字段被称为列。在面向对象的数据库中，数据容器被称为对象类，记录被称为对象，并且字段被称为属性。其它数据库体系架构可能使用其它术语。

用户通过向数据库服务器提交命令来与DBMS的数据库服务器交互，这些命令使数据库服务器对存储在数据库中的数据执行操作。用户可以是运行在与数据库服务器交互的客户端计算机上的一个或多个应用。多个用户在本文也可以被统称为用户。

数据库命令可以是符合数据库语言的数据库语句的形式。用于表达数据库命令的数据库语言是结构化查询语言(SQL)。存在许多不同的SQL版本，一些版本是标准版本并且一些版本是专有版本，并且存在各种扩展。数据定义语言(“DDL”)命令被发布到数据库服务器以创建或配置数据库对象，诸如表、视图或复杂数据类型。SQL/XML是在操纵对象关系数据库中的XML数据时使用的SQL的常见扩展。

多节点数据库管理系统由共享对相同数据库的访问的互连节点组成。典型地，节点经由网络互连并且以不同的程度共享对共享存储装置的访问，例如，对一组盘驱动器和其上存储的数据块的共享访问。多节点数据库系统中的节点可以是经由网络互连的一组计算机(例如，工作站、个人计算机)的形式。可替代地，节点可以是网格的节点，其中网格由节点组成，这些节点以服务器刀片的形式与机架上的其它服务器刀片互连。

多节点数据库系统中的每个节点都托管数据库服务器。服务器(诸如数据库服务器)是集成的软件组件和计算资源分配的组合，计算资源诸如存储器、节点和用于在处理器上执行集成的软件组件的进程，软件和计算资源的组合专用于代表一个或多个客户端执行特定的功能。

来自多节点数据库系统中的多个节点的资源可以被分配为运行特定数据库服务器的软件。软件和来自节点的资源分配的每种组合是在本文中被称为“服务器实例”或“实例”的服务器。数据库服务器可以包括多个数据库实例，这些数据库实例中的一些或全部在分开的计算机(包括分开的服务器刀片)上运行。

多租户体系架构

容器是多租户容器数据库(CDB)中的、在逻辑上对于应用看起来像单独的数据库的模式(schema)、对象和相关结构的集合。在CDB内，每个容器具有唯一的ID和名称。根数据库和每个可插拔数据库(PDB)都被视为容器。PDB隔离数据和操作，使得从用户或应用的角度看，每个PDB看起来好像它是传统的非CDB一样。每个PDB都由其自己的单独的数据库字典定义。数据库字典包括定义包含在数据库中的数据库对象的元数据。实际上，数据库字典定义了数据库的总体。数据库对象包括表、表列和表空间。表空间是用于存储各种类型的数据库对象(诸如表)的数据的一个或多个文件的集合。如果数据库对象的数据存储在表空间中，则数据库字典会将数据库对象映射到保持该数据库对象的数据的一个或多个表空间。

根容器(也称为“根”)是特定CDB内的所有PDB所属于的模式、模式对象和非模式对象的集合。每个CDB具有存储管理CDB内的所有PDB所需的系统元数据的一个根。在一些实施方式中，根不存储“用户”数据，而是存储跨CDB的PDB公共的数据，诸如对公共用户和角色、共享表、代码包等的定义。PDB是用户创建的在逻辑上对于应用看起来像单独的数据库的一组模式、对象和相关结构。因此，每个PDB可以潜在地用于存储与不同应用有关的数据，诸如一个PDB专用于托管人力资源应用，并且另一个PDB专用于托管销售应用。但是，由于共享资源在根数据库中仅存储一次，并且由PDB的数据库字典链接，因此与利用完全单独的传统数据库托管每个应用相比，避免了数据重复。此外，由于PDB本身本质上是自包含的数据库，因此为了升级或负载平衡的目的，PDB可以在不同的CDB之间容易地转移。

附图说明

在附图中：

图1示出了可以在其上实现实施例的操作环境。

图2示出了根据实施例的容器数据库的结构。

图3示出了根据实施例的利用代理可插拔数据库的示例计算环境。

图4示出了根据实施例的可插拔数据库的结构与代理可插拔数据库的结构的比较。

图5示出了根据实施例的用于在利用代理可插拔数据库的环境中执行命令的处理流程。

图6示出了根据实施例的利用应用根副本的示例环境。

图7示出了根据实施例的应用根副本的结构与应用根和代理可插拔数据库的结构的比较。

图8示出了根据实施例的用于在应用根上执行补丁和更新的处理流程。

图9示出了根据实施例的包括容器映射的应用根的结构。

图10示出了根据实施例的用于使用容器映射执行查询的处理流程。

图11示出了根据实施例的使用容器映射来过滤数据的示例。

图12示出了根据实施例的使用容器映射的分层结构来过滤数据的示例。

图13是示出可以在其上实现本发明实施例的示例计算机系统的框图。

具体实施方式

在以下描述中，出于解释的目的，阐述了许多具体细节，以便提供对本发明的透彻理解。但是，将明显的是，可以在没有这些具体细节的情况下实践本发明。在其它情况下，公知的结构和设备以框图的形式示出，以避免不必要地模糊本发明。

具体实施方式在以下部分中列出：

1.0总体概述

1.1代理可插拔数据库

1.2应用根副本

1.3容器映射

1.4查询优化

2.0数据库系统

3.0总体操作环境

3.1容器数据库

3.2根数据库

3.3撤消和重做记录

4.0代理可插拔数据库

4.1代理可插拔数据库环境

4.2代理可插拔数据库结构

4.3命令执行处理流程

5.0应用根副本

5.1应用根副本环境

5.2应用根副本结构

5.3补丁/更新执行处理流程

6.0容器映射

6.1容器映射结构

6.2容器映射修剪处理流程

6.3一层示例

6.4两层示例

7.0查询优化

7.1谓词的下推

7.2本地连接(join)的下推

7.3基于统计数据的本地连接的下推

7.5并行递归查询

7.6用于代理PDB的统计数据收集技术

8.0硬件概述

9.0附加公开

1.0总体概述

在以下解释中，诸如根、应用根、代理PDB、PDB、CDB等之类的数据库可以被描述为执行诸如更新、转发、存储、接收等之类的动作。但是，当以上面提到的方式描述数据库时，这旨在作为负责数据库在指定数据库的上下文内执行动作的数据库服务器的速写(shorthand)。

为了执行针对CDB的命令，数据库客户端连接到根数据库或PDB中的一个PDB。如果数据库客户端连接到可插拔数据库中的一个可插拔数据库，那么由数据库客户端发出的命令通常局限于该PDB内的数据。因此，从数据库客户端的角度来看，客户端连接到的PDB表现为传统数据库。但是，由于每个PDB“属于”根数据库，因此在根处执行的命令可能潜在地影响PDB中的任何PDB或所有PDB。例如，DBMS可以实现命令的关键字，该关键字使得命令在CDB内的所有PDB上执行，或通过指定子集内的PDB的ID来在PDB子集上执行。在一些实施例中，前述功能是使用SQL语句中的CONTAINERS子句实现的，CONTAINERS子句当围绕在数据库对象(诸如表)的周围时，指示该命令应当应用于跨CBD的容器的数据库对象的所有实例。例如，SQL语句“SELECT enam FROM CONTAINERS(scott.emp)WHERE CON_ID IN(45，49)”指示应当从ID为45或49的所有PDB的表“scott.emp”中选择列“enam”。

但是，命令(诸如CONTAINERS子句)通常限于访问在其上执行命令的CDB本地的可插拔数据库内的数据。为了解决这个问题，一些DBMS实现了被称为“数据库链接”的特征。数据库链接是定义从一个数据库到另一个数据库的单向通信路径的指针。数据库链接允许第一数据库的用户访问和操纵存储在另一个数据库上的对象。数据库链接在数据库的数据字典表内定义，并且包含定位另一个数据库和连接到另一个数据库所需的信息。例如，到本地数据库(诸如同一CDB内的其它PDB)的链接可以指定目标数据库的ID，而到远程数据库的链接可以指定负责的数据库服务器的网络信息(例如，域名、IP地址、端口号等等)以及远程CDB内的目标数据库的ID号。数据库链接连接是单向的，是因为连接到本地数据库A的客户端可以使用存储在数据库A中的链接来访问远程数据库B中的信息，但连接到数据库B的用户不能使用相同的链接来访问数据库A中的数据。如果数据库B上的本地用户需要访问数据库A上的数据，那么在数据库B的数据字典中定义指向数据库A的链接。一旦建立了数据库链接，由SQL语句引用的对象就可以用数据库链接的名称进行限定，以指示该命令要被转发到适当的数据库服务器以供在所链接的数据库上执行。

虽然诸如CONTAINERS子句和数据库链接之类的特征对于编译来自本地PDB和远程PDB的信息是有用的，但是上述特征缺乏位置透明性。换句话说，使用上述特征的SQL语句必须明确指定这些特征正在被使用并且提供/引用识别如何到达目标数据库的信息。例如，CONTAINERS子句通过ID识别数据库，并且数据库链接使用当链接由管理员定义时被绑定到的网络信息/数据库ID。因此，如果在利用上述特征的应用代码被编写之后，PDB的位置改变，那么应用代码必须被重新编写，以使用用于访问在PDB的新位置处的PDB的正确的机制和信息。

例如，假定CDB1包括{PDB1，PDB2}，并且应用代码包括使用CONTAINERS子句访问这两个PDB的“emp”表的SQL语句。如果在以后的某个时间点，出于负载平衡目的，PDB1被重新定位到CDB2，那么应用代码将不再产生预期效果，因为PDB1不再是CDB1的成员，并且将不能使用上述SQL语句访问。相反，将必须重新编写应用代码以使用到PDB1的数据库链接来达到预期效果。

不断重写应用代码以补偿PDB变化位置的处理给应用开发人员带来了巨大的压力，并严重限制了运输PDB的使用性。

1.1代理可插拔数据库

在实施例中，可以通过利用“代理可插拔数据库”(也称为“代理PDB”)来实现相对于PDB的位置的透明度。当PDB从一个位置移动到另一个位置时，PDB用在原始位置处的代理PDB替换，该代理PDB不包括由PDB存储的任何数据，而是包含将命令转发到当前负责该PDB的数据库服务器所需的信息。因此，如果数据库客户端通过第一数据库服务器连接到CDB1上的代理PDB，那么将从数据库客户端接收到的命令重定向到负责CDB2的第二数据库服务器，该CDB2包含代理指向的实际PDB。类似地，如果数据库客户端连接到CDB1的根并发出要在代理PDB上执行的命令，那么这些命令将被重定向到负责CDB2的数据库服务器，以便在代理指向的实际PDB上执行。在这两种情况下，第二数据库服务器都会将结果返回给第一数据库服务器，然后第一数据库服务器将结果转发到数据库客户端。在一些情况下，第一数据库服务器还可以聚合结果，诸如命令导致从多个PDB生成结果，其中这些结果在转发到数据库客户端之前需要合并的情况。

因此，对于PDB的实际位置，应用代码可以保持完全透明(agnostic)，并且不必被重写以引用移动的PDB的新位置。例如，给定SQL语句“SELECT enam FROM CONTAINERS(scott.emp)WHERE CON_ID IN 45”，即使与ID“45”对应的PDB被移动到新的CDB，也可以代替它建立代理PDB，该代理PDB使用ID“45”并使数据库服务器将命令转发到PDB的新位置。因为负责代理PDB的数据库服务器将能够使用代理PDB来访问负责PDB的新位置的数据库服务器的网络信息以及远程CDB内的PDB的ID，以便转发语句以供执行，所以应用代码可以保持相同。类似地，如果数据库链接的PDB目标要移动到新位置，那么目标可以用代理来替换，这使得通过链接发送的命令被转发到新位置而不用重新定义链接。

1.2应用根副本

除了透明度之外，代理PDB的概念还可以被用于绕过关于单个CDB可以包含的PDB数量的固有限制。由于硬件和/或软件的约束，CDB通常只能够包含至多最大数量的PDB。如果超过该数量，那么附加的PDB必须代替地存储在新的CDB内。但是，维护多个CDB对高效管理构成了挑战，高效管理诸如确保更新和补丁跨不同的CDB被一致地应用。

在单个CDB内，一些实施例引入“应用根”的概念，以同时管理由公共应用使用的多个PDB。关于应用根的附加细节可以在于2016年10月21日与本申请同时提交的由AndreKruglikov等人所写的美国申请No.##/###，###“Application Containers in ContainerDatabases”中找到，出于所有目的将该美国申请的全部内容通过引用结合于此，就像在本文完全陈述一样。类似于CDB的根，应用根分离出跨多个PDB共享的对象。虽然CDB的根存储对CDB的所有PDB公共的信息(诸如由DBMS的开发人员供应的共享对象)，但是应用根用于存储跨由同一应用使用的PDB共享的对象。这是通过使用“数据链接的”数据和“元数据链接的”数据完成的，其中在“数据链接的”数据中定义数据的元数据和数据本身驻留在应用根内，在“元数据链接的”数据中定义数据的元数据驻留在应用根内并且数据本身驻留在成员PDB内。例如，“数据链接的”数据可以表示跨所有成员PDB共享或公共的表，并且“元数据链接的”数据可以表示共享在应用根的数据库字典内定义的公共定义的表，但是表的记录在成员PDB之间是不同的。因此，CDB的根防止了跨所有PDB的共享定义和对象的重复，而应用根防止了跨由公共应用使用的PDB的共享定义和对象的重复。由于这种共享数据通常包括应用利用的表所遵循的模式，因此可以将补丁和更新应用于应用根，以便跨作为应用根的成员的所有PDB同步修改。

此外，类似于可以通过建立到根数据库的会话来访问CDB内的任何PDB的方式，建立到应用根的会话提供对作为应用根的成员的所有PDB的访问。例如，假定查询不包括限制查询应用到的PDB ID的谓词，那么包括在应用根处执行的CONTAINERS子句的查询可以将查询应用到跨应用根及其成员PDB的指定数据库对象的所有实例。

为了将应用根的概念跨多个CDB扩展，一些实施例实现被称为“应用根副本”的特征。通过建立作为应用根的成员的、指向远程CDB上的应用根的代理PDB来创建应用根副本，远程CDB上的应用根被称为应用根副本。通过将对应用根应用补丁或更新的命令通过代理PDB转发到应用根副本，应用根副本与应用根保持同步。例如，在接收到将更新应用根的命令后，负责应用根的数据库服务器针对指向远程CDB上的应用根的代理来检查应用根的成员PDB。如果这种代理PDB被定位，那么数据库服务器使用存储在代理PDB内的转发信息来将实现更新的命令转发到负责应用根副本的数据库服务器。因此，应用根和应用根副本与同一版本的应用保持同步。

例如，假设更新包括DDL命令，该DDL命令定义由应用根存储的共享模式内的表的新列，那么该DDL命令还被转发，以用于在应用根副本上执行。因此，如果将补丁或更新应用于应用根，那么由该补丁或更新封装的命令还被转发，以便在应用根副本上执行。此外，上面提到的命令可以修改作为应用根/应用根副本的成员的PDB，以实现所需的改变。因此，管理员只需要在原始应用根上执行补丁或更新，以便更新副本。另外，可以利用其自己的副本存储在其它CDB上的应用根副本来递归地重复这个处理，这有效地允许通过原始应用根管理的PDB的数量无限地向上扩展。因此，作为单独连接到每个应用根来发出命令的替代，可以在原始应用根处发出命令并通过所有链接的副本来传播这些命令。

在一些实施例中，替代地可以使用“中心辐射(hub and spoke)”模型，其中原始应用根将命令转发给所有副本，而不是使用链接的副本的链。在一些情况下，中心辐射模型可以将链中一个节点发生故障的风险最小化，并防止更新传播到链中的随后副本。此外，在由于执行命令而返回结果的情况下，中心辐射模型可以减少让多个数据库服务器将结果沿着链转发回原始应用根否则所需的资源。

此外，在应用根(除非限制到非代理PDB)发出的查询还将通过代理PDB转发到远程CDB上的应用根副本。然后，应用根副本将进而在将结果传回原始数据库服务器之前在其成员PDB上运行查询。然后，数据库服务器将能够在将结果返回给发出查询的数据库客户端之前对结果进行聚合。因此，在应用根处发出查询还允许从单个方便的位置在所有链接的应用根副本及其成员PDB上执行查询。

1.3容器映射

可由数据库用于优化查询的技术是根据取决于表的一个或多个属性的分区键对数据库表进行物理分区。然后在分区键的值与指示存储与这些值对应的表的记录的分区的存储区域之间建立映射。例如，映射可以基于范围(每个分区被指派分区键的值的范围)、列表(每个分区被指派分区键的值的列表)、散列(散列函数的值确定分区中的成员资格)、复合(上面提到的映射的组合)等等。因此，当接收到查询时，数据库服务器可以咨询映射，以确定查询所隐含(implicate)的分区并修剪掉其余的分区。

例如，假设分区键位于数据库表的“season(季节)”列上，其中P1包含“season＝spring(春季)”的记录，P2包含“season＝summer(夏季)”的记录，P3包含“season＝fall(秋季)”的记录，并且P4包含“season＝winter(冬季)”的记录。如果接收到返回季节为秋季或冬季的表的记录的查询，那么数据库服务器可以省略在P1和P2内的记录上执行查询，因为存储在这些分区中的记录被保证不匹配查询的谓词。因此，执行查询所花费的资源较少，因为那些记录被“修剪掉”并且不必由数据库服务器读取。

然而，一些实施例不是物理地对表进行分区，而是通过使用分开的PDB存储与每个分区对应的记录来逻辑地执行分区。扩展上面的季节示例，可以使用PDB1存储与分区键“season＝spring”对应的表的记录，可以使用PDB2存储与分区键“season＝summer”对应的记录，等等。该映射由存储在应用根内的称为“容器映射”的对象维护，该对象维护分区键的值与存储与这些值对应的记录的PDB之间的映射。容器映射使用的映射方案可以是上面提到的映射方案中的任何映射方案，诸如范围、列表、散列、复合等等，而没有限制。当在应用根处接收到查询时，数据库服务器咨询容器映射，以识别该查询所隐含的PDB，并且然后仅在识别出的PDB上执行查询。因此，通过不查询其它PDB，数据库服务器有效地修剪掉保证不满足查询的数据并节省读取这些记录的成本。

用作分区的PDB的数量甚至可以通过利用代理PDB和应用根副本来扩展。如上面所讨论的，可以包含在单个CDB内的PDB的数量是有限的，因此可以建立的逻辑分区的数量也是有限的。但是，可以通过建立在分区键的一些值与指向应用根副本的代理PDB之间进行映射的容器映射来绕过这个限制。然后，应用根副本维护其自己的容器映射，该容器映射进一步将数据在其成员PDB当中进行分区。因此，当在原始应用根处接收到查询时，咨询容器映射以识别作为应用根的成员的哪些PDB被隐含，并且然后在识别出的PDB上执行查询。如果代理PDB被识别出，那么查询被转发到远程CDB上的对应应用根副本。然后，应用根副本咨询其自己的容器映射，以识别作为应用根副本的成员的哪些PDB被隐含，并且然后在识别出的PDB上执行查询。结果然后被传递回应用根，并在返回到数据库客户端之前潜在地与查询产生的其它结果进行聚合。因此，可以建立指向应用根副本的代理PDB链，直到达到任何任意数量的逻辑分区为止。

例如，假设CDB1包括应用根、PDB1、PDB2和代理PDB3，代理PDB3指向还包括PDB4和PDB5的CDB2上的应用根副本。应用根存储容器映射1，容器映射1指定数据在表的国家列上进行分区，其中PDB1负责“US”数据，PDB2负责“UK”数据，并且代理PDB3负责其余的国家。应用根副本存储容器映射2，容器映射2指定数据在国家列上进行分区，其中PDB4负责“RU”数据，而PDB5负责其余国家。如果在应用根处接收到对于国家列为“US”或“RU”的表的行的查询，那么咨询容器映射1，以确定该查询隐含PDB1和代理PDB3。然后该查询在PDB1和代理PDB3上执行。但是，由于代理PDB3是指向应用根副本的代理，因此将查询转发到CDB2上的应用根副本以供执行。在远程站点处，咨询容器映射2，以确定查询仅隐含PDB4。因此，查询在PDB4上执行，并将结果返回到在应用根处接收到原始查询的站点。原始站点然后聚合从PDB4和PDB1返回的结果，并将聚合的结果转发到发出查询的客户端。

在上面的示例中，容器映射1和容器映射2都使用相同的分区键。但是，一些实施例可以选择在每个站点使用不同的分区键，以便最佳地修剪数据和优化查询。此外，上面讨论的逻辑分区方案还可以与物理分区方案相结合。例如，数据可以在各个PDB中被逻辑分区，但是根据另一个分区键或映射技术物理地存储在这些数据库内。因此，在这种实施例中，通过基于由容器映射存储的逻辑分区键来修剪掉保证不被查询隐含的PDB，在逻辑级别执行第一轮修剪。接下来，可以通过基于物理分区键而省略对保持保证不满足查询的谓词的数据的存储位置的读取操作来执行第二轮修剪。因此，与单独使用任一种技术相比，可以潜在地修剪掉更多数据，以提高查询执行效率。

1.4查询优化

当跨多个(常常位于远程的)CDB执行查询时出现的一个问题是跨网络将结果发送回原始查询的站点所需的开销。在很多情况下，计算查询的次序可以对于将需要跨网络传回的结果的大小有严重影响。

例如，考虑两个表，每个表都有1000行，并且假定接收到计算两个表的交叉连接(join)的查询。交叉连接产生两个表的笛卡尔积，这导致将第一个表的每一行与第二个表的每一行组合的行。鉴于每个表有1000行，这导致1000000行需要被运回客户端。因此，如果包含交叉连接的查询在代理PDB上执行并按原样被运送到远程站点，那么远程站点将计算交叉连接并通过网络发送回所有1000000行。但是，如果代替地将查询分别拆分为分别针对第一个表和第二个表的行的单独查询，并且由原始站点计算交叉连接，那么可以避免这种开销的大部分。因此，在这种情况下，远程站点将只需要运回2000行(每个表1000行)，然后可以计算交叉连接，而无需将大量结果从远程站点传送到首先接收到该查询的原始站点。

但是，在其它情况下，在远程站点计算连接实际上会减少将需要跨网络传送回的数据量。例如，再次考虑两个表，每个表都有1000行，并假定接收到使用两个表中两个相应列的相等性作为谓词来执行内连接的查询。内连接产生的记录数取决于相应表满足相等性谓词的行数。内连接的结果等价于取叉积(cross product)，然后返回满足谓词的行。因此，在最坏的情况下，返回的行数与上面的叉积示例相同，在最好的情况下，将不会返回任何行，并且大多数情况会落在两者之间的某处。因此，执行内连接完全有可能将导致返回比单独发出每个查询少的数据。在这种情况下，在远程站点执行连接并且然后将结果发送回原始站点效率更高。

此外，计算查询的次序还影响通过并行机制实现的效率。在一些实施例中，数据库服务器包括可以被调用以并行处理查询和其它命令的多个处理器。因此，例如，在应用根处接收到的查询可以由在第一处理器上执行的查询协调器进程来处理，但是当该查询然后在成员PDB上执行时，该查询可以被切换到在跨PDB并行执行查询的一个或多个其它处理器上执行的一个或多个其它从进程。一旦从进程完成并将结果返回到主进程，主进程就可以编译结果以返回到数据库客户端。因此，将连接下推到PDB中允许并行执行连接，从而加快查询的整体执行。否则，查询协调器进程将必须从每个从进程收集结果，并且然后自己执行连接，这在大多数情况下将显著地更慢。

因此，在一些实施例中，当数据库服务器接收到要在PDB上执行的查询时，查询优化器被调用以生成查询计划，该查询计划确定查询被处理的次序，包括哪些连接应当被下推并由从进程执行，以及哪些连接应当由查询协调器进程执行。查询优化器用于开发查询计划的因素可以包括查询是否要在代理PDB上执行(并且因此要求结果跨网络运送)、结果的估计成本(根据特定计划执行查询的资源占用空间)、搜索启发式方法(用于搜索并评估给定查询可以被执行的潜在次序)、被计算的连接的类型等等，而没有限制。

查询优化器的实施方式可以使用不同的因素来确定查询计划，但是大多数严重依赖对由查询和/或查询的各个子部分返回的结果的基数的合理估计。为了计算基数，查询优化器需要与被查询的表的列相关的准确统计数据，诸如列的基数、重复次数很多的值、列内值的分布等等。因此，在一些实施例中，每个容器(PDB、应用根、根)的数据字典存储与其成员表相关的统计数据。因此，在接收到查询时，查询优化器能够读取对应数据字典内的统计数据，以便确定查询计划。但是，在代理PDB的情况下，上面提到的统计数据将连同代理指向的PDB一起存储在远程站点处。在一些实施例中，负责PDB的数据库服务器周期性地将统计数据运送回负责代理的数据库服务器，以存储在本地站点处的代理中。因此，本地站点在准备将在代理PDB上执行的计划时，能够检索远程站点处的PDB的统计数据，以便估计PDB在各种查询计划下将运送回的结果的基数。

除了下推连接之外，下推其它查询操作符(诸如谓词、分组操作和排序操作)也有好处。通过将上面提到的操作符下推到由从进程执行，由于那些操作将由从进程并行地执行，而不是由查询协调器进程串行执行，因此可以实现更高效的查询执行。此外，在代理PDB的情况下，下推谓词过滤将常常导致需要通过网络返回较小的结果集。

2.0数据库系统

本发明的实施例用在DBMS的上下文中。因此，对DBMS的描述是有用的。

DBMS管理一个或多个数据库。DBMS可以包括一个或多个数据库服务器。数据库包括存储在持久性存储器机构(诸如一组硬盘)上的数据库数据和数据库字典。数据库数据可以存储在一个或多个数据容器中。每个容器包含记录。每条记录内的数据被组织到一个或多个字段中。在关系型DBMS中，数据容器被称为表，记录被称为行，并且字段被称为列。在面向对象的数据库中，数据容器被称为对象类，记录被称为对象，并且字段被称为属性。其它数据库体系架构可以使用其它术语。

多节点数据库管理系统由共享对一个或多个数据库的访问的互连节点组成。典型地，节点经由网络互连并且以不同的程度共享对存储装置的访问，例如，对一组盘驱动器和其上存储的数据块的共享访问。多节点数据库系统中的节点可以是经由网络互连的一组计算机(例如，工作站、个人计算机)的形式。可替代地，节点可以是网格的节点，其中网格由节点组成，这些节点以服务器刀片的形式与机架上的其它服务器刀片互连。

3.0总体操作环境

图1示出了实施例可以在其上实现的示例计算机网络环境。虽然图1仅描绘了特定数量的每种元件，但是实际环境可以具有多得多的(可能数百或数千个)图1中所示的每种元件。

在图1中，数据库服务器100、数据库服务器101和数据库服务器102(统称为“数据库服务器”)各自表示可通信地耦接到它们相应数据库(容器数据库103、容器数据库104和容器数据库105)的一个或多个计算设备上的软件和资源的组合，并且经由网络106彼此可通信地耦接并且还耦接到数据库客户端107。容器数据库103、容器数据库104和容器数据库105统称为“容器数据库”。下面在“硬件概述”中描述可以在其上实现数据库服务器的计算设备的示例。在一些实施例中，数据库服务器被配置为接受用户命令(诸如查询、数据定义语言(DDL)和数据操纵语言(DML)指令)，并且在它们相应的容器数据库上执行这些命令。

在实施例中，网络106表示一个或多个本地网络、广域网、互联网络或服务提供商网络。在一些实施例中，网络106表示互联网。

在实施例中，数据库客户端107表示一个或多个计算设备上的软件和资源的组合，该软件和资源的组合实现向数据库服务器发送命令以便检索、修改、删除或提交由容器数据库存储的数据的一个或多个应用。下面在“硬件概述”中描述可以在其上实现数据库服务器的计算设备的示例。

3.1容器数据库

图2示出了根据实施例的用于一般容器数据库的示例结构。为了示出清楚的示例，图2是关于容器数据库103描述的，但是该描述还适用于容器数据库104和容器数据库105。

容器数据库103包含由数据库服务器100托管并管理的多个数据库。数据库包括可插拔数据库PDA 220和可插拔数据库PDB 230以及与可插拔数据库PDA 320和可插拔数据库PDB 230相关联的根数据库210，如将在下面更详细解释的。在其它实施例中，容器数据库103可以包含比图2中描绘的可插拔数据库的数量更多的可插拔数据库。但是，由于固有的硬件限制，一些实施方式可以设置容器数据库103可以支持的可插拔数据库的数量的上限。根数据库210是由数据库服务器100用来全局管理容器数据库103并且存储用于成员PDB的用户可访问的“公共数据库对象”的元数据和/或数据的数据库。

可插拔数据库PDA 220包括数据库字典221。用于可插拔数据库PDA 220的数据库对象的数据存储在表空间文件226中。与用户数据类似，用于数据库字典的元数据被持久地存储在字典存储库中。包含在数据库字典221中的元数据存储在文件PDA.DBDIC中。

可插拔数据库PDB 230包括数据库字典231。表空间文件236存储可插拔数据库PDB230的数据库对象的数据。用于数据库字典231的元数据被持久性地存储在文件PDB.DBDIC中。

负责容器数据库103的数据库服务器100可以建立根数据库210或任何成员可插拔数据库的数据库会话。数据库会话连接到的数据库确定由数据库客户端107发出的命令的范围(例如，命令将在哪个(哪些)数据库上执行)、哪些权限被检查、哪些数据库字典将用于会话，等等。

3.2根数据库

根数据库210是由数据库服务器100用来全局管理容器数据库103的数据库。由根数据库210促进的重要功能是定义容器数据库103内的可插拔数据库。类似于可插拔数据库，根数据库210包括数据库字典211。根数据库的数据库字典在本文可以被称为根数据库字典。数据库字典211包含元数据，该元数据定义管理容器数据库103和其中包含的可插拔数据库所需的容器数据库103的各个方面。由数据库字典211定义的数据库对象的数据存储在表空间文件216中。

数据库字典211包括数据库对象Database_sys 303，其可以被表示为表。Database_sys 203定义容器数据库103内的可插拔数据库，并且Database_sys 203的属性各自描述可插拔数据库的方面或属性。属性“可插拔DB(Pluggable DB)”是可插拔数据库的名称或标签。属性“字典存储库(Dictionary Store)”识别保持指向成员可插拔数据库的数据库字典的元数据的字典存储库。数据库字典211中的一条记录定义可插拔数据库PDA 220及其字典存储文件PDA.DBIDC。数据库字典211中的另一条记录定义可插拔数据库PDB 230及其字典存储库PDB.DBIDC。

在实施例中，数据库字典211定义在容器数据库103中由可插拔共享或公共使用的公共数据库对象。公共数据库对象在可插拔数据库字典中定义，可插拔数据库字典包括对相应根数据库字典中的公共数据库对象的引用。公共数据库对象的示例包括供应商供应的函数、实用程序、表和视图。

根据实施例，存在两种类型的公共数据库对象：元数据链接的对象和对象链接的对象。对于这两者，公共数据库对象的元数据存储在根数据库210中。但是，对于元数据链接的对象，公共数据库对象的数据(如果有的话)存储在可插拔数据库中。因此，对于元数据链接的对象，不同的可插拔数据库可以针对同一公共数据库对象存储不同的数据。对于对象链接的对象，数据库对象的元数据和数据两者(如果有的话)都被存储在根数据库210中。因此，这种类型的公共数据库对象的数据对于容器数据库109中的可插拔数据库是相同的。

种子可插拔数据库290包含数据库对象和数据库字典。种子可插拔数据库290被克隆以快速创建初期的可插拔数据库，并且促进这种可插拔数据库的快速供应。种子可插拔数据库290包含被公共地需要和/或使用的一组基本数据库对象。例如，种子可插拔数据库290可以包含到公共数据库对象的数据库对象链接和用于访问可插拔数据库字典和其它系统信息的视图。

3.3撤销和重做记录

根数据库210的表空间文件216包括撤销文件241，数据库服务器250使用该撤销文件241存储与容器数据库103内包含的数据库上的事务相关的数据和/或元数据(“撤销记录”)。在一些实施例中，撤销记录存储在事务期间被修改的数据的前映像(image)和后映像。例如，如果在事务期间数据库服务器350修改了特定行的“STATE(州)”列以将值从“OHIO”改变为“CALIFORNIA”，则数据库服务器103还在撤销文件341中存储指定在先值“OHIO”、在后值“CALIFORNIA”以及修改的位置(例如，被修改的一个或多个数据块)的撤销记录。如果事务需要被回滚，则数据库服务器100通过对撤销记录进行回溯以反转事务已执行的任何修改。撤销记录可以存储与对应事务的状态相关的元数据，诸如指示事务是否活动、是否已经提交或是否正在回滚过程中的元数据。

撤销记录可以用于各种目的，诸如回滚事务、恢复数据库、提供读取一致性等。在一些实施例中，撤消文件241为有限大小，并且因此数据库服务器100可以覆写撤消记录以在事务发生时节省空间。例如，存储撤销记录的段可以在对应的事务(例如，通过提交或回滚)结束之后被重用。但是，在其它实施例中，数据库服务器100可以在对应的事务已经结束之后的一段时间内保留撤消记录。例如，可以保留撤消记录以便为长时间运行的查询提供读取一致性。

容器数据库103还包括重做日志240，数据库服务器100使用重做日志240来存储与在容器数据库103上执行的修改有关的数据和/或元数据(“重做记录”)。例如，每当数据库服务器100改变容器数据库103的数据块时，数据库服务器100还在重做日志240中存储识别被修改的(一个或多个)块并指定在先/在后值的重做记录。

在一些实施例中，数据库服务器基于被修改的数据库的状态来识别重做记录。例如，数据库服务器100可以维护容器数据库103的“系统更改编号”(SCN)。每当事务在底层数据库之一上提交时，数据库服务器100递增SCN。SCN在根数据库210和可插拔数据库之间共享。当数据库服务器100生成重做记录时，该重做记录被标记或以其它方式与识别被修改的数据库和对应的SCN的信息相关联。因此，SCN用于识别在创建重做记录时对应数据库的状态。在其它实施例中，时间戳可以用于相同的效果。

因此，重做日志240存储重做记录的流，该重做记录的流可以由数据库服务器100使用以当需要恢复时重放对容器数据库103的修改。

4.0代理可插拔数据库

PDB结构的主要优点之一是以快速、高效且易于使用的方式在CDB之间运输PDB的能力。但是，如上面所讨论的，可用于在PDB上发布命令的当前机制相对于PDB的位置不是透明的。因此，应用管理员不得不不断重写他们的应用代码，以确保移动后仍然可以访问PDB。

因此，在一些实施例中，当PDB从一个位置移动到另一个位置时，在原始位置处用代理PDB代替PDB，该代理PDB不包括由PDB存储的任何实际数据，而是包含向目前负责PDB的数据库服务器转发命令所需的信息。因此，在代理PDB上发出的命令被自动转发到PDB的新位置以供执行，而无需重写应用代码。

4.1代理可插拔数据库环境

图3示出了根据实施例的利用代理可插拔数据库的示例计算环境。虽然图3仅描绘了特定数量的每种元件，但实际环境可以具有多得多的(可能数百或数千个)图3中所示的每种元件。

在图3中，数据库服务器100管理包括可插拔数据库L1-LN和代理可插拔数据库300的容器数据库103，其中代理可插拔数据库300是容器数据库103上用于可插拔数据库301的代理。数据库服务器101管理容器数据库104，容器数据库104包括作为代理可插拔数据库300的目标的可插拔数据库301和可插拔数据库K1-KN。

4.2代理可插拔数据库结构

图4示出了根据实施例的代理可插拔数据库和代理指向的可插拔数据库的并排比较。参考代理可插拔数据库300和可插拔数据库301来解释图4，但是所描述的特征还适用于其它代理可插拔数据库和可插拔数据库。

在实施例中，可插拔数据库301包括数据库字典400、表空间文件401以及包括源地址403和源统计数据404的源元数据402。如上面关于图2所讨论的，数据库字典400包括定义包含在数据库中的数据库对象的元数据，并且表空间文件401是用于存储各种类型的数据库对象(诸如表)的数据的一个或多个文件的集合。

源元数据402包括代理可插拔数据库300的源地址403，其可以由负责代理可插拔数据库300的数据库服务器100的网络地址、数据库服务器100通过其接收消息的端口地址以及识别容器数据库103内的代理可插拔数据库300的ID来表示。此外，源元数据402包括与可插拔数据库301内的对象(例如，表)相关的源统计数据404，诸如值在表的各个列内的分布、各个列的基数、对于各个列通常重复的行值等等。源统计数据404可以用于帮助生成查询计划，如在下面的第7节中更详细地解释的。源地址403可以用于各种目的，诸如将统计数据404发送到代理可插拔数据库300以供存储，以便由数据库服务器100用来开发跨容器的数据库查询计划。此外，在一些实施例中，如果可插拔数据库301的位置将被移动到新位置，那么数据库服务器101可以使用源地址403来联系数据库服务器100，以更新代理可插拔数据库300的目标地址307以引用新的位置。因此，可以避免目标地址307的手动更新，以减少管理员为了运输可插拔数据库301所需要执行的任务的数量。

在实施例中，代理可插拔数据库300包括目标元数据405，目标元数据405包括目标地址406和目标统计数据407。目标地址406可以由管理代理可插拔数据库300指向的可插拔数据库301的数据库服务器101的网络地址、数据库服务器101通过其接收消息的端口地址以及识别容器数据库104内的可插拔数据库301的ID来表示。目标地址406用于将在代理可插拔数据库302上执行的命令转发到可插拔数据库301。目标统计数据407表示与可插拔数据库301相关的统计数据404，该统计数据404已经由数据库服务器101发送到数据库服务器100以存储在代理可插拔数据库300中。目标统计数据407然后被用于开发用于经由代理可插拔数据库300使用可插拔数据库301的查询的查询计划。取决于数据库管理系统108使用的统计数据搜集机制，统计数据404和目标统计数据407可能并不总是保持完全同步。统计数据搜集机制的示例在下面的第7.5节中描述。

4.3命令执行处理流程

图5以框图形式示出了根据实施例的在代理可插拔数据库上执行命令的示例处理流程。在其它实施例中，与图5中描绘的处理流程相比，图5中描绘的框可以以不同的次序执行、被分成更大的框集合、或合并成更小的框集合。下面的解释假设处理流程在图3描绘的环境中执行，其中命令由数据库服务器100接收，以供代理可插拔数据库300执行。此外，在命令在代理可插拔数据库上执行的流程分支中，解释假设代理可插拔数据库300是在其上执行命令的数据库。在一些实施例中，命令可能需要在多个PDB上执行，诸如命令在影响多个成员PDB的根/应用根上执行的情况。在这种情况下，图5的处理流程可以针对PDB使用多个附加进程顺序地或并行地重复。

在图5中，在框500处，数据库服务器100从数据库客户端107接收要在容器数据库103的可插拔数据库上执行的命令。例如，命令可以是查询、DML命令、DDL命令、控制管理功能的命令等等。在一些实施例中，数据库服务器100执行从客户端接收消息的被称为“侦听器”的多个进程，并且调用查询协调器进程，该查询协调器进程使命令通过从进程在可插拔数据库上执行。可插拔数据库可以由容器数据库103内的每个可插拔数据库唯一的ID来指定。例如，数据库客户端107可以通过指定ID来建立与具体可插拔数据库的数据库会话，然后提交让数据库服务器100在可插拔数据库上执行的一个或多个命令。作为另一个示例，数据库客户端107可以建立到根数据库210或应用根的数据库会话，然后提交引用可插拔数据库的ID的命令。

在框501处，数据库服务器100确定要在其上执行命令的可插拔数据库是否为代理。在一些实施例中，数据库服务器100检查可插拔数据库以确定可插拔数据库是否为代理。例如，可插拔数据库可以存储将可插拔数据库识别为代理的元数据，诸如标志。在其它实施例中，数据库服务器100可以针对识别可插拔数据库是否是代理的元数据来检查根数据库210的数据库字典211或应用根的数据库字典。如果可插拔数据库是代理，那么数据库服务器100前进到框503。否则，数据库服务器100前进到框502。

在框502处，数据库服务器100在可插拔数据库上执行命令。在实施例中，当数据库服务器100在可插拔数据库上执行命令时，效果取决于在框500处接收到的命令的类型。例如，如果命令是查询，那么数据库服务器100可以读取可插拔数据库的一个或多个记录并应用一个或多个谓词和/或连接来创建结果集。如果命令是DML命令，那么数据库服务器100可以添加、删除或修改可插拔数据库的数据库对象的一个或多个记录。如果命令是DDL命令，那么数据库服务器100可以定义新的数据库对象、修改现有对象的定义或删除可插拔数据库的现有数据库对象。

在框507处，数据库服务器100将结果返回到数据库客户端107。假设在框500处接收到的命令产生结果，那么在框507处，数据库服务器100将结果返回到数据库客户端107。但是，一些类型的命令可以不返回任何结果，或者可以只返回指示命令是否已成功执行的确认。

在框503处，数据库服务器100识别代理可插拔数据库300的目标可插拔数据库301的地址。在实施例中，数据库服务器100检查目标元数据405内包含的目标地址406，以识别用于管理可插拔数据库301的数据库服务器101的网络地址和/或端口地址以及容器数据库104内的可插拔数据库301的ID。

在框504处，数据库服务器100将命令转发到数据库服务器101。在实施例中，数据库服务器100生成寻址到数据库服务器101的网络/端口地址的消息，该消息包含在框500处接收的命令，并且包括容器数据库104内的可插拔数据库301的ID。但是，在其它实施例中，数据库服务器100首先经由数据库服务器101建立到可插拔数据库301的会话，然后在会话建立之后提交该命令。

在框505处，数据库服务器101在可插拔数据库301上执行命令。在实施例中，当数据库服务器101在可插拔数据库301上执行命令时，效果取决于在框500处接收到的命令的类型。例如，如果命令是查询，那么数据库服务器101可以从可插拔数据库301读取一个或多个记录并应用一个或多个谓词来创建结果集。如果命令是DML命令，那么数据库服务器100可以从可插拔数据库301添加、删除或修改数据库对象的一个或多个记录。如果命令是DDL命令，那么数据库服务器100可以定义新的数据库对象、修改现有对象的定义、或删除可插拔数据库301的一个或多个现有数据库对象。

在框506处，数据库服务器101将执行命令的结果返回到数据库服务器100。假设在框500处接收到的命令在框505处执行时产生结果，那么数据库服务器101在框506处将结果返回到数据库服务器100。但是，一些类型的命令可以不返回任何结果，或者可以只返回指示命令是否已被成功执行的确认。在框507处，数据库服务器100然后将结果返回到数据库客户端107。

5.0应用根副本

“应用根”是可以被用于同时管理由公共应用使用的多个PDB的机制。类似于CDB的根，应用根分离出跨多个PDB共享的对象。虽然CDB的根存储对于CDB的所有PDB公共的信息(诸如由DBMS的开发人员提供的共享对象)，但是应用根用于存储跨由相同应用使用的可插拔数据库共享的对象。因此，CDB的根防止跨所有PDB的共享对象的重复，而应用根防止跨由公共应用使用的PDB的共享对象的重复。由于这种共享数据通常包括由应用使用的表所遵循的模式，因此可以将补丁和更新应用于应用根，以便跨作为应用根成员的所有PDB同步修改。但是，与单个根数据库不同，给定的容器数据库可以具有多个应用根，以将用于不同应用的PDB分组在一起。

为了跨多个CDB扩展应用根的概念，一些实施例实现被称为“应用根副本”的特征。通过建立作为应用根的成员的、指向远程CDB上的应用根的代理PDB来创建应用根副本，其中远程CDB上的应用根被称为应用根副本。通过将实现对于应用根的补丁或更新的命令通过代理PDB转发到应用根副本来保持应用根副本与应用根同步。例如，在接收到将对应用根应用更新的命令后，负责应用根的数据库服务器检查应用根的成员PDB是否有指向远程CDB上的应用根的代理。如果这种代理PDB被定位，那么数据库服务器使用存储在代理PDB内的转发信息将实现更新的命令转发到负责应用根副本的数据库服务器。因此，应用根和应用根副本与相同版本的应用保持同步。

在一些实施例中，补丁或更新表示已经使用关键字(诸如开始/结束块)被捆绑在一起的命令集合或者作为当被执行时将应用根修改为新版本或子版本的脚本的一部分。在一些情况下，作为补丁或更新的一部分，集合中包括附加命令，这些附加命令还引发成员PDB的改变，以实现补丁或更新。

5.1应用根副本环境

图6示出了根据实施例的利用应用根副本的示例计算环境。虽然图6仅描绘了特定数量的每种元件，但实际环境可以具有多得多的(可能数百或数千个)图6中所示的每种元件。

在图6中，数据库服务器100管理包括可插拔数据库L1-LN、代理可插拔数据库602和应用根600的容器数据库103，其中应用根600由容器数据库104中的应用根副本601复制。数据库服务器101管理包括可插拔数据库K1-KN和复制应用根600的应用根副本601的容器数据库104。

5.2应用根副本结构

图7示出了根据实施例的应用根、代理可插拔数据库与应用根副本的并排比较。参考应用根600、应用根副本601和代理可插拔数据库602来解释图7，但是所描述的特征还适用于其它应用根和应用根副本。

在实施例中，应用根副本601包括数据库字典700、表空间文件701以及包括源地址703和源统计数据704的源元数据702。如以上关于图2所讨论的，数据库字典700包括定义包含在数据库中的数据库对象的元数据，并且表空间文件701是用于存储各种类型的数据库对象(诸如表)的数据的一个或多个文件的集合。在一些实施例中，数据库字典700或与应用根副本601相关联的元数据包括识别容器数据库104内的哪些PDB是应用根副本601的成员的信息。因此，如果命令的执行需要的话，那么数据库服务器101可以向成员数据库传播发布到应用根副本601的命令。

源元数据702包括代理可插拔数据库602的源地址703，该源地址703可以由负责代理可插拔数据库602的数据库服务器100的网络地址、数据库服务器100通过其接收消息的端口地址以及识别容器数据库103内的代理可插拔数据库602的ID来表示。此外，源元数据702包括与应用根副本601内的对象(例如，表)相关的源统计数据704，诸如值在表的各个列内的分布、各个列的基数、各个列通常重复的行值等等。在一些实施例中，源统计数据704还包括与成员PDB相关的统计数据，但是用于对成员PDB的统计数据保持跟踪的存储方法并不关键。

例如，每个PDB和应用根可以维持它们自己的统计数据，其中统计数据被收集并发送到代理可插拔数据库602。作为另一个示例，用于每个成员PDB的统计数据可以在应用根副本601处被聚合，以用于传送到代理可插拔数据库602。源统计数据704可以被用来帮助生成查询计划，如在下面的第7节中更详细地解释的。源地址703可以用于各种目的，诸如将统计数据404发送到代理可插拔数据库602以供存储，以便由数据库服务器100用来开发跨容器的数据库查询计划。此外，在一些实施例中，如果将应用根副本601的位置移动到新位置，那么数据库服务器101可以使用源地址703来联系数据库服务器100以更新代理可插拔数据库602的目标地址707来引用该新位置。因此，可以避免目标地址708的手动更新，以减少管理员为了运输应用根副本601而需要执行的任务的数量。

在实施例中，代理可插拔数据库602包括目标元数据707，目标元数据707包括目标地址708和目标统计数据709。目标地址406可以由管理代理可插拔数据库602指向的应用根副本601的数据库服务器101的网络地址、数据库服务器101通过其接收消息的端口地址以及识别容器数据库104内的应用根副本601的ID来表示。目标地址708用于将在代理可插拔数据库602上执行的命令转发到应用根副本601。目标统计数据709表示已经由数据库服务器101发送到数据库服务器100以供存储在代理可插拔数据库602中的与应用根副本601相关的源统计数据704。目标统计数据709然后被用于开发经由代理可插拔数据库602使用应用根副本601的查询的查询计划。取决于数据库管理系统108利用的统计数据搜集机制，源统计数据704和目标统计数据709可能并不总是保持完全同步。统计数据搜集机制的示例在下面的第7.5节中描述。

在实施例中，应用根600包括数据库字典705和表空间文件706。如上面关于图2所讨论的，数据库字典705包括定义包含在数据库中的数据库对象的元数据，并且表空间文件706是用于存储用于各种类型的数据库对象(诸如表)的数据的一个或多个文件的集合。在一些实施例中，数据库字典705或与应用根600相关联的元数据包括识别容器数据库103内的哪些PDB是应用根600的成员的信息。因此，如果命令的执行需要的话，那么数据库服务器100可以向成员PDB传播发布到应用根600的命令。

5.3补丁/更新执行处理流程

图8以框图形式示出了根据实施例的向应用根应用补丁或更新的示例处理流程。在其它实施例中，与图8中描绘的处理流程相比，图8中描绘的框可以以不同的次序执行、被分成更大的框集合、或合并成更小的框集合。下面的解释假设在图6描绘的环境中执行处理流程，其中命令是应用由数据库服务器100接收的补丁或更新。此外，在命令被转发到应用根副本的处理流程的分支中，应用根被假设为应用根600，应用根副本被假设为应用根副本601，并且代理PDB被假设为代理可插拔数据库602。

在图8中，在框800处，数据库服务器100从数据库客户端107接收要在容器数据库103内定义的应用根600上执行的命令。例如，命令可以是查询、DML命令、DDL命令、控制管理功能的命令、应用补丁或更新的命令等等。在一些实施例中，数据库服务器100执行从客户端接收消息的被称为“侦听器”的多个线程或处理，然后使得命令在应用根600上被执行。应用根600可以由容器数据库103内的每个可插拔数据库唯一的ID指定。例如，数据库客户端107可以与应用根600建立数据库会话，然后提交用于让数据库服务器100在应用根600上执行的一个或多个命令。

在框801处，数据库服务器100确定该命令是否应用补丁或更新。在一些实施例中，应用补丁或更新的命令包括指示正在由命令执行补丁或更新的一个或多个特定关键字。在一些情况下，命令之后可以有实现补丁或更新的命令集合(诸如由开始/结束块标记的命令)。在其它实施例中，命令可以指定包含在补丁或更新期间要应用的命令集合的脚本。如果数据库服务器100确定命令应用补丁或更新，那么数据库服务器前进到框803。否则，数据库服务器100前进到框802。

在框802处，数据库服务器100在应用根600上执行命令。在实施例中，当数据库服务器100在应用根600上执行命令时，效果取决于在框800处接收到的命令的类型。例如，如果命令是查询，那么数据库服务器100可以读取应用根600和/或一个或多个成员PDB的一个或多个记录，聚合结果，并将聚合的结果返回到数据库客户端。如果命令是DML命令，那么数据库服务器100可以添加、删除或修改应用根600内和/或一个或多个成员PDB内的数据库对象的一个或多个记录。如果命令是DDL命令，那么数据库服务器100可以定义新数据库对象、修改现有对象的定义或删除应用根600和/或一个或多个成员PDB内的现有数据库对象。如果命令应用补丁或更新，那么数据库服务器100可以执行实现补丁或更新的命令集合。

在一些情况下，在应用根600处执行命令可以使命令或命令的部分在应用根600的一个或多个成员PDB上执行。在这种情况下，可以遵循图5的处理流程，以进行在该命令隐含的成员PDB中的每个成员PDB上的执行，以处理执行在代理PDB上进行的情况。执行图8的处理流程的进程可以产生附加的从进程，这些从进程执行跨受影响的PDB的并行的命令执行。在查询的情况下，框802处命令的执行细节将在第7节中更详细地讨论。作为高级别解释，命令由数据库服务器的查询协调器进程接收，然后查询协调器进程产生在受影响的PDB上并行执行查询的一个或多个从进程，并且可以重写该查询以执行一个或多个优化。当查询协调器进程接收到从一个或多个从进程返回的结果时，查询协调器进程在返回之前聚合结果。

在一些实施例中，命令或部分命令是否在应用根600下的多个PDB上执行取决于由命令访问的数据库对象。例如，在元数据链接的对象的情况下，数据驻留在应用根600下的PDB中，而不是应用根600本身中。因此，这种命令只能通过访问应用根600下的PDB来完成，并且除非命令明确地将命令的应用限制到某些成员PDB，否则这将应用到应用根600下的所有PDB。

在框803处，数据库服务器100确定应用根600的成员PDB是否是指向应用根副本601的代理。在一些实施例中，数据库服务器100咨询与应用根600相关联的元数据，以确定成员PDB是否是指向应用根副本601的代理。例如，应用根600的数据库字典705可以包括识别哪些PDB是应用根600的成员、成员PDB是否是代理以及代理成员PDB是否指向应用根副本的表。在应用根600下定义了指向不同副本的多个代理PDB的情况下，图8的从框804到框807的处理流程可以针对识别出的代理中的每个代理串行地或并行地重复。但是，在其它实施例中，可以在代理可插拔数据库602与应用根600之间拆分元数据。例如，应用根600的数据库字典705可以识别成员PDB，但是存储在代理可插拔数据库602内的元数据可以指示它是否是代理以及它是否指向应用根副本601。如果不存在作为指向应用根副本601的代理的成员PDB，那么数据库服务器100前进到框802。否则，数据库服务器100前进到框804。

在框804处，数据库服务器100识别应用根副本800的地址。在实施例中，数据库服务器100检查包含在代理可插拔数据库602的目标元数据707内的目标地址708，以识别管理应用根副本601的数据库服务器101的网络地址和/或端口地址以及容器数据库104内的应用根副本601的ID。

在框805处，数据库服务器100将补丁或更新转发到数据库服务器101。在实施例中，数据库服务器100生成寻址到数据库服务器101的网络/端口地址的消息，该消息包含实现补丁或更新的命令集合并且包括应用根副本601的ID。但是，在脚本内识别出命令集合的情况下，数据库服务器100可以在发出使脚本由数据库服务器101在应用根副本601上执行的命令之前将脚本转发到数据库服务器101。

在框807处，数据库服务器101在应用根副本601上执行补丁或更新。在实施例中，当数据库服务器101在应用根副本601上执行补丁或更新时，补丁或更新的效果取决于实现补丁或更新的命令的类型。例如，在DML命令的情况下，数据库服务器101可以添加、删除或修改应用根副本601内和/或一个或多个成员PDB内的数据库对象的一个或多个记录。在DDL命令的情况下，数据库服务器101可以定义新数据库对象、修改现有对象的定义或者删除应用根副本601和/或一个或多个成员PDB内的现有数据库对象。在一些实施例中，可以在框807结束时将结果传递回到数据库服务器100，该结果诸如补丁或更新已被成功应用于应用根副本807的确认。

6.0容器映射

如前面所提到的，在一些实施例中，不是实现表的物理分区，而是使用分开的PDB逻辑地实现分区，以存储与每个分区对应的记录。该映射由存储在应用根内的称为“容器映射”的对象维护，该对象维护分区键的值与存储与这些值对应的记录的PDB之间的映射。由容器映射使用的映射方案并不关键，并且可以包括诸如范围、列表、散列、复合等等之类的方案而没有限制。当在应用根处接收到查询时，数据库服务器咨询容器映射，以识别查询所隐含的PDB，并且然后仅在已识别出的PDB上执行查询。因此，通过不查询其它PDB，数据库服务器有效地修剪掉了保证不满足查询的数据，并节省了读取被修剪的PDB内的记录的成本。

6.1容器映射结构

图9示出了根据实施例的包括容器映射的应用根的示例结构。参考应用根900来解释图9，但是所描述的特征也适用于其它应用根。图9。

在图9中，应用根900包括数据库字典901、表空间文件902和容器映射903(包括分区标准904和对应的可插拔数据库905)。数据库字典901和表空间文件902具有与上面参考图7描述的数据库字典706和表空间文件707相同的结构。

容器映射903包括两个子部分：分区标准904和对应的可插拔数据库905。分区标准可以取决于由给定实施例利用的分区方案而不同。例如，在范围分区方案的情况下，分区标准904将指定已经用于跨成员PDB对表进行分区的表的一个或多个列的值的范围。作为另一个示例，在列表分区方案的情况下，分区标准904将列出已经用于跨成员PDB对表进行分区的表的一个或多个列的值集合。对应的可插拔数据库905然后为分区标准904中的每一个指定存储与分区标准904匹配的表的记录的PDB。因此，当在应用根900处接收到查询时，可以将查询与分区标准904比较，以确定哪些对应的可插拔数据库905具有可以潜在地与查询匹配的记录。然后可以搜索这些PDB，以查找与查询匹配的记录，而其余的PDB被有效地修剪掉并且不需要被搜索。

6.2容器映射修剪处理流程

图10示出了根据实施例的用于使用容器映射在应用根处执行查询的示例处理流程。在其它实施例中，与图10中描绘的处理流程相比，图10中描绘的框可以以不同的次序执行、被分成更大的框集合或合并成更小的框集合。下面的解释假设在应用根900处接收查询，并且应用根900在由数据库服务器100管理的容器数据库103内。

在图10中，在框1000处，数据库服务器100接收要在应用根900处应用的查询。在一些实施例中，查询指定一个或多个数据库对象(例如，表)、要应用到在指定的数据库对象内包含的记录的零个或更多个谓词、零个或更多个连接操作以及零个或更多个排序/分组操作。在一些实施例中，在与应用根900建立会话之后，从数据库客户端107接收查询。

在框1001处，数据库服务器100确定容器映射906是否已经在应用根900处被启用。在一些实施例中，数据库服务器100检查与应用根900相关联的元数据(例如，标志)以确定是否为应用根900启用了容器映射906，该元数据可以被包含在根数据库210的数据库字典211、应用根900的数据库字典901或其它存储位置内。但是，在其它实施例中，数据库服务器100可以检查应用根900是否存在容器映射906，并且假设在存在容器映射906的情况下容器映射906被启用。如果容器映射906被启用，那么数据库服务器100前进到框1002，否则数据库服务器100前进到框1003。

在框1002处，数据库服务器100在应用根900的成员PDB上执行查询。应用根900本身被认为是应用根900的成员。例如，数据库服务器100可以从应用根900的数据库字典901读取，以确定成员PDB，并且然后在每个成员PDB上发出查询。取决于数据库服务器100的实现，可以使用并发地运行以从受影响的PDB的指定数据库对象读取记录的多个附加的从进程，并且应用指定的谓词以将记录过滤成结果集，来在每个成员PDB上串行地或并行地执行查询。此外，如果在框1000处接收到的查询中包括排序或分组操作，那么可以在框1004处应用排序或分组操作。此外，当查询被传递到从进程以供执行时，查询可以被重写，以实现一个或多个优化，如下面在第7节中所描述的。从进程所遵循的处理流程可以镜像(mirror)上面关于图5所描述的处理流程，以处理其中查询可能在代理PDB上执行的实施例。取决于在框10000处接收到的查询以及由数据库服务器100开发的查询计划，数据库服务器100可以在框1002处跨在其上执行查询的每个PDB内的不同数据库对象的记录执行一个或多个连接。

在一些情况下，查询可以限制查询在应用根900的哪些成员PDB上执行，诸如通过在查询中指定成员PDB的ID或者与查询一起使用限制其应用的关键字来实现。查询甚至可以仅限于应用根900本身。此外，在执行查询期间的某些情况下，可能发现成员PDB不包含指定的(一个或多个)数据库对象。在这种情况下，取决于实施例，执行可能会产生错误，或者结果集可以作为空或空值返回。

在框1003处，数据库服务器100基于分区标准识别所隐含的可插拔数据库。在实施例中，数据库服务器100分析查询，以确定哪些谓词与用作应用根900的容器映射906的分区标准907的(一个或多个)属性相关。数据库服务器100然后基于分区标准907确定哪些对应的可插拔数据库908包含可能潜在地满足查询的记录。例如，考虑容器映射906指定PDB A存储列K＜10的记录，PDB B存储列10≤K≤100的记录并且PDB C存储列K＞100的记录的情况。如果接收到包括谓词“K＜90”的查询，那么数据库服务器100将PDB A和PDB B识别为被查询隐含，因为这两个PDB都存储K可以低于90的记录。但是，由于PDB C只包含K＞100的记录，因此PDB C的记录都不可能满足查询。因此，在这个例子中，在框1003处，PDB C可以被安全地修剪并且不被数据库服务器100识别。

在框1004处，数据库服务器100在框1003处识别出的PDB上执行查询。取决于数据库服务器100的实现，可以使用多个并发运行以从每个PDB的指定数据库对象读取记录的附加从进程，并应用指定谓词以将记录过滤成结果集，来在每个成员PDB上串行地或并行地执行查询。此外，如果在框1000处接收到的查询中包括排序或分组操作，那么可以在框1004处应用排序或分组操作。此外，当查询被传递到从进程以供执行时，查询可以被重写，以实现一个或多个优化，如下面在第7节中所描述的。从进程所遵循的处理流程可以镜像上面关于图5所描述的处理流程，以处理查询可能在代理PDB上执行的实施例。取决于在框10000处接收到的查询和由数据库服务器100开发的查询计划，数据库服务器100可以在框1004处执行一个或多个连接。

在一些实施例中，查询是否在应用根600下的多个PDB上执行取决于由该命令访问的数据库对象。例如，在元数据链接的对象的情况下，数据驻留在应用根900下的PDB中，而不是应用根900本身中。因此，这种命令只能通过访问应用根900下的PDB来完成，并且除非命令明确地将命令的应用限制到某些成员PDB，否则这将应用到应用根900下的所有PDB。

在一些实施例中，作为优化，原始查询被剥离了已经保证满足的谓词，以减少应用查询所需的时间。例如，如果查询包括谓词“country＝FR OR US”，那么所隐含的PDB可以是表示保持国家是FR的记录的逻辑分区的第一PDB，以及表示保持国家是US的记录的逻辑分区的第二PDB。当查询被发送到第一PDB或第二PDB时，谓词可以被去除，因为分区方案已经确保谓词被满足。因此，关于该谓词的附加检查将需要由读取来自第一PDB和第二PDB的记录的进程来执行。

在一些实施例中，在成员PDB上执行查询可以使查询在应用根900的位于远程CDB上的应用根副本上执行。远程应用根副本所遵循的处理与图10的处理流程相同。换句话说，在相继链接的应用根副本处递归地执行该处理流程。

在框1005处，数据库服务器100聚合执行查询的结果。在实施例中，数据库服务器100通过将在每个成员PDB上执行查询的结果连结(concatenate)在一起来聚合结果。此外，基于由数据库服务器100开发的查询计划，在框1002或框1004的执行期间，一些连接和/或分组/排序操作可能未被应用。因此，还未由从进程执行的连接操作和/或分组/排序操作代替地在框1006处最终结果返回到数据库客户端107之前在框1005处在聚合期间执行。在框1006处，数据库服务器100将结果返回给到数据库客户端1007。在一些实施例中，返回到数据库客户端1007的结果表示查询(包括由查询指定的任何谓词过滤和/或连接操作)应用于应用根900及其成员PDB的结果。

6.3一层示例

图11示出了根据实施例的使用容器映射来过滤数据的示例。

在图11中，数据库服务器100管理包括PDB 1、PDB 2、PDB 3、PDB 4和应用根900的容器数据库103。应用根900包括使用列表分区的容器映射1100，该列表分区将包含国家列的记录分区为针对USA(美国)的PDB 1、针对FR(法国)的PDB 2、针对RU(俄罗斯)的PDB 3以及针对其余国家的PDB 4。

在图11的示例中，数据库服务器100从数据库客户端接收查询，该查询选择来自表的、国家是USA或RU的记录。数据库服务器100然后咨询应用根900的容器映射1100以确定所隐含的PDB。在这种情况下，PDB 1和PDB3被查询隐含，因为两者都有潜力包含满足查询的记录。数据库服务器100然后在PDB 1和PDB 3上执行查询，并且结果被聚合并返回到发出查询的数据库客户端。

6.4两层示例

图11中的先前示例示出了使用容器映射来过滤单个CDB内的数据。但是，通过使用代理数据库和应用根副本，容器映射的概念可以跨多个CDB应用。

在图12中，数据库服务器100管理包含PDB IL、PDB 2L、PDB 3L、代理PDB 4L和应用根900的容器数据库103。应用根900包含容器映射1201，容器映射1201关于表的国家列进行列表分区，使得PDB IL被映射到USA、PDB 2L被映射到FR、PDB 3L被映射到RU，并且代理PDB4L被映射到其余部分。数据库服务器101维护容器数据库104，容器数据库104包括PDB 1K、PDB 2K和作为应用根900的副本的应用根副本1200。应用根副本1200包括容器映射1202，容器映射1202关于国家列进行列表分区，使得PDB 1K被映射到PDB 1K，其余国家被映射到PDB2K。

在图12的示例中，数据库服务器100接收从表中选择国家列是FR或DE的记录的查询。然后数据库服务器100咨询应用根900的容器映射1201，以确定查询所隐含的PDB，在这种情况下这些PDB是PDB 2L和代理PDB 4L，因为它们都具有可能满足查询的记录。数据库服务器100然后在识别出的PDB上执行查询。在PDB 2L的情况下，查询正常执行，并且结果准备与来自代理可插拔PDB 4L的结果进行聚合。但是，代理PDB 4L是指向应用根副本1200的代理PDB。因此，数据库服务器100将查询转发给数据库服务器101，数据库服务器101然后检查由应用根副本1200存储的容器映射1202，以确定CDB 104内由查询所隐含的PDB。在这种情况下，PDB 1K是CDB 104上的由查询所隐含的唯一PDB。数据库服务器101然后在PDB 1K上执行查询，并将结果返回到数据库服务器100，以与来自PDB 2L的结果聚合并返回到客户。

7.0查询优化

通过使用关键字(诸如上面讨论的CONTAINERS子句)，可以在根和/或应用根内的数据库会话期间查询多个PDB中的数据。例如，以下查询将返回来自多个PDB的数据，

QA1：SELECT ename FROM CONTAINERS(emp)WHERE CON_ID IN(45，49)；

CONTAINERS子句的CON_ID列被包括在containers子句返回的每一行中，并识别每个返回行源自的PDB。在上面的查询中，CON_ID识别与ID 45和49相关联的PDB。

查询由多个进程使用并行从执行框架执行。这些进程包括查询协调器进程和一个或多个从进程，该一个或多个从进程在本文被称为PQ(并行查询)从进程。访问PDB的PQ从进程在PDB的会话上下文内执行；PDB的数据字典附加到PQ从进程的会话。

此外，访问PDB的PQ从进程执行基于用于针对PDB执行的原始查询生成的递归查询。递归查询可能与原始查询不相同(或者甚至语义上不等价)。在一些实施例中，递归查询去除与跨多个PDB执行查询相关联的谓词和/或关键字，并且替代地将原始查询变换为适合于在单个PDB上执行的递归查询。例如，以下递归查询QR1可以为查询QA1生成并被给予PQ从进程，

QR1：SELECT ename FROM emp；

然后，由一个或多个单独的从进程集合针对与ID 45和49相关联的PDB执行以上QR1。

7.1谓词的下推

在一些实施例中，通过将谓词并入到递归查询中来“下推”过滤谓词。例如，

QA2：SELECT ename FROM CONTAINERS(emp)WHERE emp.age＜18；

QR2：SELECT ename FROM emp WHERE emp.age＜18

QA2中的谓词“emp.age＜18”在递归查询QR2中被下推。因此，谓词将由每个PQ从进程并行检查，而不是由查询协调器进程串行执行。由于原始查询缺少基于CON_ID的谓词，因此递归查询QR2在作为接收查询的应用根的成员的所有开放的PDB上执行。如果在其上执行递归查询的成员PDB是代理，那么查询被发送到链接的远程PDB。

7.2本地连接的下推

在另一个实施例中，可以将连接操作下推以由在PDB的上下文内的PQ从进程在PDB上执行。例如，当containers(DBA_VIEWS)和containers(DBA_TABLES)连接在一起时，假设行基于containers()的列CON_ID列的匹配被连接，那么可以在PDB的上下文内本地完成这种连接。如果查询内不存在这样的相等性谓词，那么不能下推连接，因为连接将必须跨从多个不同PDB获取的行执行，这是查询协调器进程在接收到来自PQ从进程的结果集之后将必须执行的。在一些实施例中，默认假定用于连接的列CON_ID相等性，因为这种情况可以被并行地高效执行。因此，查询协调器进程可以隐含地添加CON_ID相等性，或者从进程可以被配置为假定指定CON_ID相等性的谓词存在。但是，在这种情况下，可以支持关键字来专门指示CON_ID相等性谓词不存在，以便不限制用户可以执行的查询类型。

例如考虑查询，

QA3：

select(＊)

from containers(dba_tables)t，contianers(dba_views)v

where t.table_name＝v.view_name

and t.con_id＝v.con_id

以上查询的替代表示是：

QA3’：

select count(＊)

from containers(select t.table_name from dba_tables t，dba_views v

where t.table_name＝v.view_name)

containers子句内的语句被执行为PDB内的递归查询(用PDB的上下文执行的PQ从进程)，实际上导致在每个PDB内并行地本地执行对“t.table_name＝v.view_name”的本地连接。响应于在查询QA3中检测到基于CON_ID的连接而生成递归查询QA3′。

7.3基于统计数据的本地连接的下推

连接操作的下推可以基于为表收集的优化器统计数据。在代理PDB的情况下，用于远程链接的PDB的表的统计数据也存储在代理PDB处。例如，以下查询引用其数据存储在应用根中的对象链接的表dep以及其数据存储在每个PDB中的元数据链接的表emp。假设优化器统计数据指示dep是小表，而表emp是大表。基于优化器统计数据，本地连接被推到在PDB的上下文内执行，如由以下查询所示。

QA4：

Select emp.name，dep.name from containers(emp)，dep where emp.dep＝dep.i and

dep.groupi＝5

这里，查询协调器进程确定dep是小表并且表emp是每个PDB中的大表。因此，在每个PDB内至少部分地本地执行连接是有利的。下面示出了可以为执行本地连接而生成的示例递归查询：

QR4：

Select emp.name fron emp wherein emp.dep IN(list_of_deps)

递归查询返回与“dep.groupid＝5”的dep中的行连接的所有行。递归查询使用列出具有“dep.groupid＝5”的行的每个部门的id的存储器中数据结构“list_of_deps”。list_of_deps的数据由应用根生成，并经由递归查询传入。

7.4并行递归查询

当用于应用容器的查询协调器生成涉及跨PDB查询的执行计划时，查询协调器决定在应用容器的上下文中执行的从进程的并行度(DOP，例如从进程的数量)。这些从进程中的任何一个都可以被指派在PDB的上下文内执行递归查询的工作。由查询协调器指派的负责在PDB的上下文内执行递归查询的PQ从进程在本文被称为PDB从进程。

然后，PDB从进程可以决定用于在PDB内执行递归查询的DOP。如果决定了大于1的DOP，那么PDB从进程成为用于执行递归查询的多个PQ从进程的查询协调器。因此，在一个POD DBMS上的一个应用容器内，跨PDB查询可以由多个查询协调器执行，一个在应用根的上下文内操作，并且一个或多个作为协调递归查询的多个PDB从进程的执行的查询协调器在PDB的上下文内操作。

7.5用于代理PDB的统计数据收集技术

如上面所讨论的，查询协调器进程依赖准确的统计数据以便在查询计划期间进行确定，诸如确定是否应当将本地连接下推到递归查询中。但是，在代理PDB的情况下，诸如表和其它数据库对象的尺寸和分布之类的统计数据存储在远程PDB处，而不是被本地存储。这个问题可以通过多种方式解决。在一个实施例中，负责远程PDB的数据库服务器可以周期性地将统计数据推回到代理PDB，或者响应于某些触发器(诸如记录被更新、删除或添加到数据库对象)而推回统计数据。在另一个实施例中，负责代理的数据库服务器可以通过发送请求从远程PDB周期性地拉取统计数据或响应于某些事件(诸如接收到需要在远程PDB上执行的查询)拉取统计数据。取决于由实施例实现的技术，存储在代理和远程PDB处的统计数据可能不完全同步。但是，即使在这种情况下，统计数据仍然提供查询协调器进程可以依赖以开发查询计划的估计。

8.0硬件概述

根据一个实施例，本文描述的技术由一个或多个专用计算设备或一个或多个通用计算设备来实现。专用计算设备可以是硬连线的以执行这些技术，或者可以包括诸如被永久性编程以执行这些技术的一个或多个专用集成电路(ASIC)或现场可编程门阵列(FPGA)之类的数字电子设备，或者可以包括被编程为按照固件、存储器、其它存储装置或其组合中的程序指令来执行这些技术的一个或多个通用硬件处理器。这些专用计算设备还可以将定制的硬连线逻辑、ASIC或FPGA与定制的编程组合来实现这些技术。专用计算设备可以是台式计算机系统、便携式计算机系统、手持式设备、联网设备或者合并硬连线逻辑和/或程序逻辑以实现这些技术的任何其它设备。通用计算设备可以包括一个或多个通用硬件处理器，该一个或多个通用硬件处理器被编程为按照固件、存储器、其它存储装置或其组合中的程序指令来执行这些技术。

例如，图13是示出本发明的实施例可以在其上实现的示例计算机系统1300的框图。计算机系统1300包括用于传送信息的总线1302或者其它通信机制，以及与总线1302耦接用于处理信息的硬件处理器1304。硬件处理器1304可以是例如通用微处理器。

计算机系统1300还包括耦接到总线1302用于存储信息和要由处理器1304执行的指令的主存储器1306，诸如随机存取存储器(RAM)或其它动态存储设备。主存储器1306还可以用于在要由处理器1304执行的指令执行期间存储临时变量或其它中间信息。这种指令当存储在处理器1304可访问的非瞬态存储介质中时，使计算机系统1300成为被定制为执行指令中所指定的操作的专用机器。

计算机系统1300还包括耦接到总线1302的只读存储器(ROM)1308或者其它静态存储设备，用于为处理器1304存储静态信息和指令。诸如磁盘或光盘之类的存储设备1310被提供，并且耦接到总线1302，以用于存储信息和指令。

计算机系统1300可以经由总线1302耦接到显示器1312，诸如阴极射线管(CRT)，以用于向计算机用户显示信息。包括字母数字键和其它键的输入设备1314耦接到总线1302，用于向处理器1304传送信息和命令选择。另一种类型的用户输入设备是游标控制器1316，诸如鼠标、轨迹球或者游标方向键，用于向处理器1304传送方向信息和命令选择并且用于控制显示器1312上的游标移动。这种输入设备通常具有允许设备指定平面中的位置的在两个轴(第一轴(例如，x)和第二轴(例如，y))上的两个自由度。

计算机系统1300可以利用与计算机系统相结合使计算机系统1300成为专用机器或者把计算机系统1300编程为专用机器的定制的硬连线逻辑、一个或多个ASIC或FPGA、固件和/或程序逻辑来实现本文所述的技术。根据本发明的一种实施例，本文的技术由计算机系统1300响应于处理器1304执行包含在主存储器1306中的一条或多条指令的一个或多个序列而执行。这种指令可以从诸如存储设备1310之类的另一存储介质读到主存储器1306中。包含在主存储器1306中的指令序列的执行使处理器1304执行本文所述的处理步骤。在可替代实施例中，硬连线的电路系统可以代替软件指令或者与软件指令结合使用。

如在本文所使用的，术语“存储介质”是指存储使机器以特定方式操作的数据和/或指令的任何非瞬态介质。这种存储介质可以包括非易失性介质和/或易失性介质。非易失性介质包括例如光盘或磁盘，诸如存储设备1310。易失性介质包括动态存储器，诸如主存储器1306。存储介质的常见形式包括，例如，软盘、柔性盘、硬盘、固态驱动器、磁带、或者任何其它磁性数据存储介质、CD-ROM、任何其它光学数据存储介质、具有孔模式的任何物理介质、RAM、PROM和EPROM、FLASH-EPROM、NVRAM、任何其它存储器芯片或盒式磁带。

存储介质与传输介质不同但是可以与传输介质结合使用。传输介质参与在存储介质之间传送信息。例如，传输介质包括同轴线缆、铜线和光纤，包括包含总线1302的导线。传输介质还可以采取声波或光波的形式，诸如在无线电和红外线数据通信中产生的声波或光波。

把一条或多条指令的一个或多个序列携带到处理器1304以供执行可以涉及各种形式的介质。例如，指令最初可以在远端计算机的磁盘或固态驱动器上携带。远端计算机可以把指令加载到其动态存储器中并且利用调制解调器经电话线发送指令。位于计算机系统1300本地的调制解调器可以接收电话线上的数据并且使用红外线发送器把数据转换成红外线信号。红外线检测器可以接收在红外线信号中携带的数据并且适当的电路系统可以把数据放在总线1302上。总线1302把数据携带到主存储器1306，处理器1304从主存储器1306检索指令并执行指令。由主存储器1306接收的指令可以可选地在被处理器1304执行之前或之后被存储在存储设备1310上。

计算机系统1300还包括耦接到总线1302的通信接口1318。通信接口1318提供耦接到网络链路1320的双向数据通信，其中网络链路1320连接到本地网络1322。例如，通信接口1318可以是综合业务数字网络(ISDN)卡、线缆调制解调器、卫星调制解调器、或者提供到对应类型的电话线的数据通信连接的调制解调器。作为另一个示例，通信接口1318可以是提供到兼容的局域网(LAN)的数据通信连接的LAN卡。还可以实现无线链路。在任何此类实现中，通信接口1318都发送和接收携带表示各种类型信息的数字数据流的电信号、电磁信号或光信号。

网络链路1320通常通过一个或多个网络提供到其它数据设备的数据通信。例如。网络链路1320可以通过本地网络1322提供到主机计算机1324或者到由互联网服务提供商(ISP)1326操作的数据设备的连接。ISP 1326又通过现在通常称为“互联网”1328的全局分组数据通信网络提供数据通信服务。本地网络1322和互联网1328都使用携带数字数据流的电信号、电磁信号或光信号。通过各种网络的信号以及在网络链路1320上并通过通信接口1318的信号是传输介质的示例形式，其中这些信号把数字数据带到计算机系统1300或者携带来自计算机系统1300的数字数据。

计算机系统1300可以通过(一个或多个)网络、网络链路1320和通信接口1318发送消息和接收数据，包括程序代码。在互联网示例中，服务器1330可以通过互联网1328、ISP1326、本地网络1322和通信接口1318发送对于应用程序的请求代码。

接收到的代码可以在其被接收到时由处理器1304执行，和/或存储在存储设备1310或其它非易失性存储装置中，用于以后执行。

在前面的说明书中，已经参考可以依据实施方式而不同的众多的具体细节描述了本发明的实施例。因此，说明书和附图将被认为是说明性的而不是限制性的。本发明的范围的唯一且排他的指示以及申请人旨在作为本发明的范围的是以权利要求发布的具体形式从本申请发布的权利要求集合的书面和等价范围，包括任何后续的补正。

9.0附加的公开

在以下条款中描述了附加的实施例：

1.一种方法，包括：在第一数据库服务器处从数据库客户端接收要在包含多个可插拔数据库的第一容器数据库的第一可插拔数据库上执行的命令；响应于确定第一可插拔数据库是代理，第一数据库服务器识别包含在第二容器数据库内并能够通过第二数据库服务器访问的该代理的目标可插拔数据库，其中第二容器数据库不同于第一容器数据库并且第二数据库服务器不同于第一数据库服务器；第一数据库服务器将命令转发到第二数据库服务器以在目标可插拔数据库上执行；响应于从第二数据库服务器接收到执行命令的结果，第一数据库服务器将结果转发到数据库客户端。

2.如条款1的方法，其中识别目标可插拔数据库涉及读取存储在第一可插拔数据库内的信息，该信息识别以下当中的一个或多个：第二数据库服务器的主机名、第二数据库服务器的网络地址、通过其将消息发送到第二数据库服务器的端口、或者该目标可插拔数据库在第二容器数据库内的标识符。

3.如条款1-2中任一项的方法，还包括：第一数据库服务器从第二数据库服务器接收指示目标可插拔数据库已被运输到能够通过第三数据库服务器访问的第三容器数据库的消息，并且作为响应，基于以下当中的一个或多个来更新信息：第三数据库服务器的网络地址、通过其向第三数据库服务器发送消息的第二端口、或者该目标可插拔数据库在第三容器数据库内的标识符。

4.如条款1-3中任一项的方法，还包括：响应于确定第一可插拔数据库不是代理，在第一可插拔数据库上执行命令。

5.如条款1-4中任一项的方法，其中目标可插拔数据库存储与存储在目标可插拔数据库内的数据库对象相关的一个或多个统计数据，并且该方法还包括第一数据库服务器从第二数据库服务器接收该一个或多个统计数据，并将该一个或多个统计数据存储在第一可插拔数据库内。

6.如条款1-5中任一项的方法，其中，在数据库客户端建立到第一可插拔数据库的会话之后，从数据库客户端接收要在第一可插拔数据库上执行的命令。

7.如条款1-6中任一项的方法，其中，在数据库客户端建立到第一可插拔数据库是其成员的应用根的会话之后，从数据库客户端接收要在第一可插拔数据库上执行的命令。

8.如条款7的方法，其中命令指定将由指令集实现的补丁或更新应用于应用根，并且该方法还包括：响应于接收到命令，确定第一可插拔数据库是否指向应用根副本；响应于确定第一可插拔数据库指向应用根副本，在将命令转发到第二数据库服务器之前，将该命令替换为实现补丁或更新的指令集。

9.如条款7-8中任一项的方法，其中要在第一可插拔数据库上执行的命令在包括第一可插拔数据库的两个或更多个可插拔数据库上执行，并且该方法还包括：在将执行命令的结果转发到数据库客户端之前，聚合从两个或更多个可插拔数据库返回的结果。

10.如条款9的方法，其中命令由第一数据库服务器的查询协调器进程接收，该查询协调器进程产生被用于并行地在两个或更多个可插拔数据库上执行命令的两个或更多个从进程。

11.如条款1的方法，其中第一容器数据库的每个可插拔数据库包括定义可插拔数据库内的一个或多个数据库对象的相应数据库字典。

12.存储指令的一个或多个非瞬态计算机可读介质，指令当由一个或多个计算设备执行时使得如条款1-11中记载的方法中的任一种方法被执行。

13.一种包括一个或多个计算设备的系统，该一个或多个计算设备包括至少部分地由计算硬件实现的、被配置为实现如条款1-11中记载的方法中的任一种方法的步骤的组件。

Claims

1.一种用于执行针对数据库的命令的方法，包括：

在第一数据库服务器处从数据库客户端接收要针对包含多个可插拔数据库的第一容器数据库的第一可插拔数据库执行的特定命令；

其中所述第一可插拔数据库是包含在第二容器数据库内的第二可插拔数据库的代理，并且包含用于将查询转发到托管所述第二容器数据库的第二数据库服务器的数据，其中第二容器数据库不同于第一容器数据库并且第二数据库服务器不同于第一数据库服务器；

响应于确定所述第一可插拔数据库是所述第二可插拔数据库的代理：

第一数据库服务器基于用于转发查询的所述数据将所述特定命令转发到第二数据库服务器以针对所述第二可插拔数据库执行；

响应于从第二数据库服务器接收到执行所述特定命令的结果，第一数据库服务器将所述结果转发到数据库客户端。

2.如权利要求1所述的用于执行针对数据库的命令的方法，其中识别所述第二可插拔数据库涉及读取存储在第一可插拔数据库内的信息，所述信息识别以下当中的一个或多个：第二数据库服务器的主机名、第二数据库服务器的网络地址、通过其将消息发送到第二数据库服务器的端口、或者所述第二可插拔数据库在第二容器数据库内的标识符。

3.如权利要求2所述的用于执行针对数据库的命令的方法，还包括：

第一数据库服务器从第二数据库服务器接收指示所述第二可插拔数据库已被运送到能够通过第三数据库服务器访问的第三容器数据库的消息，并且作为响应，第一数据库服务器基于以下当中的一个或多个来更新所述信息：第三数据库服务器的网络地址、通过其向第三数据库服务器发送消息的第二端口、或者所述第二可插拔数据库在第三容器数据库内的标识符。

4.如权利要求1-3中的任一项所述的用于执行针对数据库的命令的方法，还包括：

响应于确定第一可插拔数据库不是代理，在第一可插拔数据库上执行所述特定命令。

5.如权利要求1-3中任一项所述的用于执行针对数据库的命令的方法，其中所述第二可插拔数据库存储与存储在所述第二可插拔数据库内的数据库对象相关的一个或多个统计数据，并且所述方法还包括第一数据库服务器从第二数据库服务器接收所述一个或多个统计数据，并将所述一个或多个统计数据存储在第一可插拔数据库内。

6.如权利要求1-3中任一项所述的用于执行针对数据库的命令的方法，其中，接收要在第一可插拔数据库上执行的特定命令是在数据库客户端建立到第一可插拔数据库的会话之后从数据库客户端接收的。

7.如权利要求1-3中任一项所述的用于执行针对数据库的命令的方法，其中，接收要在第一可插拔数据库上执行的特定命令是在数据库客户端建立到第一可插拔数据库是其成员的应用根的会话之后从数据库客户端接收的。

8.如权利要求7所述的用于执行针对数据库的命令的方法，其中所述特定命令指定将由指令集实现的补丁或更新应用于所述应用根，并且所述方法还包括：

响应于接收到所述特定命令，确定第一可插拔数据库是否指向应用根副本；

响应于确定第一可插拔数据库指向所述应用根副本，在将所述特定命令转发到第二数据库服务器之前，将所述特定命令替换为实现所述补丁或更新的所述指令集。

9.根据权利要求7所述的用于执行针对数据库的命令的方法，其中要在第一可插拔数据库上执行的特定命令在包括第一可插拔数据库的两个或更多个可插拔数据库上执行，并且所述方法还包括：

在将执行所述特定命令的结果转发到数据库客户端之前，聚合从所述两个或更多个可插拔数据库返回的结果。

10.如权利要求9所述的用于执行针对数据库的命令的方法，其中所述特定命令由第一数据库服务器的查询协调器进程接收，所述查询协调器进程产生被用于并行地在所述两个或更多个可插拔数据库上执行所述特定命令的两个或更多个从进程。

11.如权利要求1-3中任一项所述的用于执行针对数据库的命令的方法，其中第一容器数据库的每个可插拔数据库包括定义可插拔数据库内的一个或多个数据库对象的相应数据库字典。

12.存储指令的一个或多个非瞬态计算机可读介质，所述指令当由一个或多个计算设备执行时使得如权利要求1-11中所述的用于执行针对数据库的命令的方法中的任一种方法被执行。

13.一种包括一个或多个计算设备的系统，所述一个或多个计算设备包括至少部分地由计算硬件实现的、被配置为实现如权利要求1-11中所述的用于执行针对数据库的命令的方法中的任一种方法的步骤的组件。

14.一种包括用于执行如权利要求1-11中所述的用于执行针对数据库的命令的方法中的任一种方法的步骤的部件的装置。