池、销售池。数据库只能属于单个的数据库池。没有必要池中所有的数据库都提供相同的全局服务集合；个体数据库可以只支持由该池提供的服务的子集。但是，提供相同全局服务的所有数据库必须属于同一个池。数据库池可以具有只能管理该池的专门的管理员集合。因此，数据库池简化了管理，并且提高了大型数据库云中的安全性。
[0041]全局数据服务目录
[0042]根据一种实施例，全局数据服务目录(GDS目录)是全局数据服务框架100的另一个组件。⑶S目录是由⑶S框架100维护的信息的存储库(r印ository)。在⑶S目录中存储的信息可以包括，例如，数据库云的配置和运行时状态。更具体而言，在GDS目录中维护的信息可以包括全局服务上的数据、每个全局服务的属性、及云的所有逻辑和物理组件:数据库池、区域、全局服务管理器和数据库实例。目录也可以包含有关云的复制和网络拓扑的数据。
[0043]可以在⑶S目录中维护的信息项的例子包括，但不限于:
[0044]数据库云中哪里的数据库被组织成“数据库池”，每个数据
[0045]库池的成员
[0046]对于每个全局服务哪些数据库时启用的
[0047]对于每个全局服务哪些数据库是优选的
[0048]为每个全局服务规定的“基数”
[0049]下文将更详细地描述在GDS目录中存储的各个信息如何被服务框架100使用。
[0050]在一种实施例中，每个数据库云有单个的GDS目录。但是，为了高可用性的目的，可以维护目录的多个副本。在图2中，GDS目录示为存储在GDS目录数据库270中。但是，⑶S目录可以存储在任何类型的存储库中，包括平面文件。而且，虽然⑶S目录数据库270被描绘为单个存储设备，但是GDS目录数据库270可以存储在若干个存储设备上，其中每个设备都可以存储GDS目录的所有或分布的部分。
[0051]处理连接请求
[0052]如上所述，当全局服务框架100从客户端接收到连接请求时，全局服务框架100选择客户端应该被连接到哪个数据库服务器实例，并且促进客户端到所选数据库服务器实例的连接。
[0053]根据一种实施例，客户端通过将它们的连接请求发送到其中一个它们的全局服务管理器来将它们的连接请求传递到全局服务框架100。例如，来自客户端152的建立连接的请求可以发送到全局服务管理器202或204，这两者对于客户端152都是本地的。来自客户端162的连接请求可以发送到全局服务管理器206或208。类似地，来自客户端164的连接请求可以发送到全局服务管理器210。
[0054]在某些情况下，客户端可以将连接请求发送到没有与该客户端关联的区域的全局服务管理器。例如，如果由于某种原因本地全局服务管理器都不可用，诸如本地区域中的所有数据库都停用，则这种情况会发生。例如，如果区域X的全局服务管理器202和204两者都停用，则客户端152可以将其连接请求发送到区域Y的全局服务管理器206，即使全局服务管理器206对客户端152不是本地的。注意，这种重新连接可以通过客户端中间件自动地完成；因此每个应用不需要实现这个逻辑。
[0055]接收到连接请求的全局服务管理器然后选择要与发送该请求的客户端连接的数据库服务器实例。为了说明起见，假设客户端154将连接请求发送到全局服务管理器202。作为响应，全局服务管理器202可以使得在客户端154和数据库服务器实例102之间形成连接。根据一种实施例，全局服务管理器只在建立连接时参与其中。在这种实施例中，一旦连接被建立，客户端就直接与它们已连接到的数据库系统对话。
[0056]在以上给出的例子中，响应于客户端154的连接请求，建立了单个连接。但是，在许多系统中，客户端建立客户端侧的连接池，其可以包括到许多数据库服务器实例的连接。此外，客户端的连接池也可以包括到同一数据库服务器实例的多个连接。因此，来自客户端154的连接请求可以请求建立五个连接，并且响应于该请求，全局服务管理器202可以在客户端154和数据库服务器实例102之间建立两个连接、在客户端154和数据库服务器实例104之间建立一个连接、在客户端154和数据库服务器实例108之间建立一个连接、以及在客户端154和数据库服务器实例110之间建立一个连接。
[0057]伙伴区域
[0058]根据一种实施例，每个区域具有指定的“伙伴区域”。一般而言，特定区域的伙伴区域是如果该特定区域的GSM被阻止处理职责则伙伴区域的GSM将接管该特定区域的职责的区域。
[0059]例如，当区域中所有的GSM都停用时，伙伴区域中的一个或多个GSM开始充当具有失效GSM的区域的监听者。因此，如果区域X中的GSM 202和204停用，并且区域Y是区域X的伙伴区域，则来自区域Y的GSM 206和208中的一个可以开始充当区域X的监听者，同时它继续充当区域Y的监听者。在这些情况下，如果来自区域X的客户端156发出连接请求，则连接请求将由来自区域Y的GSM 206和208中的一个处理。
[0060]很明显，利用某个区域中的GSM建立数据库连接并不意味着GSM选择建立连接的数据库将与GSM在同一区域。任何GSM都可以将连接请求转发到提供适当服务的任何数据库。因此，即使GSM202和204停用，GSM 206 (其驻留在区域Y中)也可以使客户端156连接到数据库服务器实例107 (其驻留在区域X中)。
[0061]伙伴区域Y的GSM可以承担通常由区域X的GSM处理的所有职责，不仅仅是用于连接请求监听的职责。例如，伙伴区域Y的一个或多个GSM也可以接管为区域X生成事件的职责。作为另一个例子，除了为本地客户端生成度量之外，GSM也可能需要为其指定作为伙伴的区域计算度量，并且为驻留在那个区域的客户端发布这些度量。例如，当那个区域中的所有GSM都停用时，这可能是需要的。
[0062]注册
[0063]根据一种实施例，全局服务和可用于运行全局服务的数据库实例两者都向GDS框架注册。具体而言，对于全局服务，注册信息指定与每个全局服务相关联的一组属性。属性控制何时及何地启动服务、到它们的连接如何以及是否负载平衡、连接如何以及是否进行故障转移，等等。根据一种实施例，为服务注册的属性除其它事项之外还指定:
[0064]运行时负载平衡目标
[0065]连接时负载平衡目标
[0066]基于角色的服务
[0067]连接故障转移特性
[0068]优选/可用数据库
[0069]复制延迟
[0070]区域密切关系
[0071]对于数据库实例注册，当数据库加入数据库云时，或者在停机后重启时，数据库向云中的所有GSM注册。接收注册的GSM通过查询⑶S目录确定哪些服务可以在被注册的数据库上启动来响应。那些服务然后在数据库服务器实例上启动，并且数据库服务器实例因此成为与要求那些全局服务的客户端的连接的候选者。
[0072]选择在哪建立连接的因素
[0073]如上所述，全局服务管理器负责响应来自客户端的连接请求选择建立哪些连接。根据一种实施例，全局服务管理器基于多种因素做出这种选择，以便在可用于全局数据服务框架100的数据库服务器实例中高效地平衡连接负载。这些因素可以包括，例如:
[0074]哪些数据库服务器实例能够提供请求者要求的服务
[0075]哪些数据库服务器实例已被指定为用于请求者要求的服务的
[0076]“优选”实例
[0077]数据库服务器实例的性能度量
[0078]请求客户端所属的区域
[0079]数据库服务器实例所属的区域
[0080]区域之间的延时
[0081]所请求全局服务的区域密切关系
[0082]下文将更详细地描述每个这些因素。但是，这些因素仅仅是全局数据服务框架100在选择与哪些数据库服务器实例连接给定客户端时可以考虑的因素的例子。具体的因素以及赋予每个因素的权重可以随着实现的不同而变化。
[0083]区域密切关系
[0084]根据一种实施例，每个全局服务可以对一些区域具有比其它区域更强的“密切关系”。具体而言，在一种实施例中，每个全局服务有两个参数:“locality(本地性)”和“reg1rufailoveH区域故障转移)”，其允许用户指定服务与区域密切关系的程度。取决于这些参数的值，可以支持各种策略。例如，当locality参数设置为“anywhere (任何地方)”(缺省值)时，缺省的区域密切关系策略可以生效。在这种情况下，客户端连接请求被路由到能够为所请求服务满足负载平衡目标的最佳数据库。数据库的选择是基于其性能和其中客户端和数据库驻留的区域之间的网络延时。目标数据库可以从任何区域中选择。如果在不同区域中的数据库被平等地加载，则这个策略将优先级给予本地区域，即，客户端被连接到属于同一区域的数据库。只有区域间数据库性能的差异超过(overweight)网络延时时，才进行区域间的连接。
[0085]如果存在为其中locality参数设置为“anywhere”的服务指定的优选/可用数据库，则在数据库池的级别维护服务基数。这意味着，如果服务在优选数据库上停用，则它将在可用数据库上启动并且池中服务提供者的数量将保持不变。当在可用数据库上启动服务时，优先级给予其中服务停止的区域中的数据库。如果在本地区域中没有这个服务的可用数据库，则从邻近区域中随机选择可用数据库。
[0086]当locality参数设置为“local_only (仅本地)”时，客户端连接请求被路由到能为所请求服务满足负载平衡目标的客户端区域中的最佳数据库。数据库的选择仅基于其性能。“local reg1n only (仅本地区域)”服务可以同时在多个区域中提供，但是来自一个区域的客户端永远不会被连接到另一个区域中的数据库。
[0087]如果存在为其中locality参数设置为“loCal_only”的服务指定的优选/可用数据库，则在区域级别维护服务基数。这意味着，如果服务在优选数据库上停用，则它将在同一区域中可用数据库上启动，因此该区域中服务提供者的数量将保持不变。如果在本地区域中没有这个服务的可用数据库，则不采取任何行动并且降低服务基数。如果在本地区域中没有数据库提供该服务，则客户端连接请求被拒绝。这基本上意味着，如果服务与本地区域具有密切关系，则数据库的服务基数在每个区域中独立地进行维护。
[0088]当本地性参数设置为“local_only”并且指定了 “reg1n_failover”选项时，“affinity to local reg1n with inter-reg1n failover (具有区域间故障转移的与本地区域的密切关系)”的策略有效。该策略与“local_0nly”相同，唯一不同之处是，如果本地区域中没有数据库提供服务，则不是拒绝客户端的请求，而是将它转发到另一个区域中具有启动的所请求服务的最佳数据库(就负载和网络延时而言)。这种服务故障转移不会使得该服务在另一个区域中的可用数据库上被启动。不启动该服务的原因是，具有与本地区域的密切关系，数据库基数按每个区域进行维护并且不应该由于另一个区域中的服务故障而改变。如果区域的数据库由于区域间的故障转移而变得过载，则数据库管理员(DBA)可以手动地为该服务添加优选数据库。
[0089]数据库服务器实例性能度量
[0090]关于性能度量，在一种实施例中，每个数据库服务器实例定期地向