专用 Exadata 基础结构上的自治 AI 数据库中的计算管理
专用 Exadata 基础结构上的自治 AI 数据库在配置自治 AI 数据库资源时提供了两个计算模型。它们是:
-
ECPU :ECPU 是计算资源的抽象度量。ECPU 基于从计算和存储服务器池弹性分配的内核数。您需要至少 2 个 ECPU 来预配自治 AI 数据库。
预配新数据库、克隆现有数据库以及纵向扩展或收缩现有数据库的 CPU 资源时,CPU 计数默认为 2 个 ECPU,以 1 为增量。例如,上面的下一个可用 ECPU 数为 3。
您可以在基于 ECPU 的容器数据库上为开发人员创建自治 AI 数据库。它们是免费的自治 AI 数据库,开发人员可以使用它来构建和测试新应用。有关详细信息,请参阅 Autonomous AI Database for Developers 。
-
OCPU :OCPU 是计算资源的物理度量。OCPU 基于启用超线程的处理器的物理核心。
注: OCPU 是传统计费度量,已为专用 Exadata 基础结构上的自治 AI 数据库停用。Oracle 建议将 ECPU 用于所有新的和现有的 Autonomous AI Database 部署。有关更多信息,请参见 Oracle Support Document 2998755.1 。
预配新数据库、克隆现有数据库以及纵向扩展或收缩现有数据库的 CPU 资源时:
-
CPU 计数默认为 1 个 OCPU,以 1 为增量。例如,下一个超过 1 的可用 OCPU 数为 2。
-
对于不需要整个 OCPU 的数据库,您可以按 0.1 OCPU 为增量从 0.1 分配 OCPU 到 0.9。这样,您可以过度预配 CPU,并在每个基础设施实例上运行更多数据库。有关更多详细信息,请参阅 CPU 过量供应。
-
自治 Exadata VM 集群的计算类型适用于其所有自治容器数据库和自治 AI 数据库实例。
计算管理
自治 AI 数据库实例部署到自治 Exadata VM 集群 (AVMC) 中,并部署到其子自治容器数据库 (ACD) 中。Exadata 基础结构能够运行多个 AVMC。预配 AVMC 资源时分配的 CPU 是其自治 AI 数据库可用的总 CPU 。创建多个 AVMC 时,每个 AVMC 可以具有自己的总 CPU 值。
在启动多个 VM 自治 AI 数据库功能之前创建的 Exadata 基础结构 (EI) 资源的任何 Oracle Public Cloud 部署上都无法使用多个 VM 自治 Exadata VM 集群。对于在启动多个 AVMC 功能后创建的 X8M 代及以上 Exadata 基础结构资源,每个 AVMC 都会为您选择的 Exadata 系统配置的每个服务器创建一个集群节点。有关在不同用户组中约束这些总 CPU 的信息,请参见“区间配额如何影响 CPU 管理”。
注:在给定的 Exadata 基础结构上可以创建的最大 AVMC 和 ACD 资源数因硬件生成而异。有关每一代约束的详细信息,请参阅资源限制和基础设施配置的特性。
在 AVMC 或 ACD 级别,可用于创建数据库的 CPU 总数称为可用 CPU 。在 AVMC 资源级别,可用 CPU 将等于 CPU 总数,直到您创建第一个 ACD。创建 ACD 后,每个节点 8 个 ECPU 或 2 个 OCPU 会从 AVMC 的可用 CPU 分配给新 ACD。因此,AVMC 资源级别的可用 CPU 会相应减少。在该 ACD 中创建第一个自治 AI 数据库时,新数据库会占用最初分配的 CPU(每个节点 8 个 ECPU 或 2 个 OCPU)。如果新数据库需要超过 8 个 ECPU 或 2 个 OCPU,则它们将从父 AVMC 的可用 CPU 进行分配,方法是减少父 AVMC 级别的可用 CPU。在每个 ACD 中创建更多 ACD 并预配自治 AI 数据库时,可用的 CPU 值会相应发生变化。
自治 Exadata VM 集群级别的可用 CPU 应用于其所有自治容器数据库。如果使用自动缩放功能,则容器数据库可用的 CPU 计数将变得重要,如“自动缩放时 CPU 分配”中所述。
同样,当您手动扩展自治 AI 数据库的 CPU 时,CPU 将从其父 AVMC 级别的可用 CPU 中消耗,并且其值会相应地更改。
创建自治 AI 数据库时,默认情况下,Oracle 会预留更多 CPU,以确保即使节点发生故障,数据库也能以至少 50% 的容量运行。在预配 ACD 时,您可以将节点间预留的 CPU 百分比更改为 0% 或 25%。有关说明,请参见 Create an Autonomous Container Database 中的节点故障转移保留。这些额外的 CPU 不包括在计费中。
当自治 AI 数据库运行时,将按当前分配给数据库的 CPU 数计费(无论是在初始创建时指定还是以后通过手动缩放操作指定)。此外,如果为数据库启用了自动缩放,则系统会针对数据库自动缩放后所使用的任何其他 CPU 每秒向您收取费用。有关如何测量和计算计费的详细信息,请参阅 CPU 计费详细信息。
当自治 AI 数据库停止时,不会对您计费。但是,对于整个部署,分配给它的 CPU 数不会返回到其父 AVMC 级别的可用 CPU。
终止或缩减自治 AI 数据库后,分配给自治 AI 数据库的 CPU 数不会立即返回到其父 AVMC 级别的可用 CPU,以便进行整体部署。在重新启动父容器数据库之前,它们将继续包含在可供其父容器数据库使用的 CPU 计数中。这些 CPU 称为可回收 CPU 。父 AVMC 级别的可回收 CPU 是其所有 ACD 的可回收 CPU 的总和。当 ACD 重新启动时,它将其所有可回收 CPU 返回到其父 AVMC 级别的可用 CPU。
重新启动自治容器数据库 (Autonomous Container Database,ACD) 是一项联机操作,可在整个集群中以滚动方式完成,如果根据使用透明应用连续性的优秀实践进行配置,则不会导致应用停机。
提示:您可以从自治 Exadata VM 集群 (AVMC) 或自治容器数据库 (ACD) 的详细信息页面中跟踪本文中讨论的不同计算 (CPU) 属性。有关指导,请参阅资源使用情况跟踪。
自动缩放时 CPU 分配
通过自动缩放功能,自治 AI 数据库的 CPU 和 IO 资源使用量是其分配的 CPU 计数的 3 倍。如果 CPU 预配过多,如果 CPU 计数的三倍导致值小于 1,则会将该值舍入到下一个整数。仅 OCPU 支持 CPU 超额预配。有关详细信息,请参阅 CPU 过量供应。
为了确保没有单个自治 AI 数据库可以自动扩展以使用池中可用于整体部署的所有 CPU,Oracle Autonomous AI Database on Dedicated Exadata Infrastructure 使用自治容器数据库作为限制控制。
在 ACD 中预配启用了自动缩放的自治 AI 数据库时,如果该 ACD 中的可用 CPU 小于新数据库的 3 倍 CPU 值,则会在该 ACD 中预留其他 CPU。这些 CPU 称为保留的 CPU 。保留的 CPU 可确保 ACD 级别的可用 CPU 始终大于或等于该 ACD 中启用了自动缩放的最大数据库的 3 倍 CPU 值。这些预留的 CPU 仍可用于在此 ACD 中创建或手动缩放自治 AI 数据库。
自动扩展自治 AI 数据库时,Oracle Autonomous AI Database on Dedicated Exadata Infrastructure 在其父容器数据库中查找空闲 CPU。如果有空闲 CPU 可用,则会扩展自治 AI 数据库;否则,不会扩展。数据库本身具有大量空闲时间,因此自动缩放是最大限度提高资源使用率的一种方式,同时可以控制成本并保持与其他自治容器数据库中的数据库的良好隔离。
如果用于自动缩放自治 AI 数据库的 CPU 来自另一个正在运行的轻负载自治 AI 数据库,因此未使用其所有分配的 CPU,则 Oracle Autonomous AI Database on Dedicated Exadata Infrastructure 会自动缩放自动缩放的数据库,前提是负载在另一个数据库上增加,并且它需要重新分配 CPU。
以托管四个运行 4-CPU 自治 AI 数据库的自治容器数据库为例,所有这些数据库都启用了自动缩放。容器数据库可用于自动缩放的 CPU 数量为 12。如果由于负载增加而需要将其中一个数据库自动缩放到 4 个 CPU 以上,则 Oracle Autonomous AI Database on Dedicated Exadata Infrastructure 仅当一个或多个其他数据库轻量加载而未使用所有分配的 CPU 时才会执行自动缩放操作。此示例的计费成本至少为 16 个 CPU,因为所有四个 4-CPU 数据库都在运行。
相比之下,假设自治容器数据库托管四个运行的 2-CPU 自治 AI 数据库,所有数据库都启用了自动缩放,一个数据库停止了 8-CPU 自治 AI 数据库。容器数据库可用于自动缩放的 CPU 数量再次为 16。如果某个正在运行的数据库由于负载超过 2 个 CPU 而需要自动缩放,则 Oracle Autonomous AI Database on Dedicated Exadata Infrastructure 可以使用分配给已停止的 8-CPU 数据库的 CPU 执行操作。在此示例中,四个正在运行的数据库最多可以同时使用 8 个额外的 CPU,而不会占用彼此分配的 CPU。此示例的计费成本仅为 8 个 CPU,因为只有四个 2-CPU 数据库始终在运行。
对于任何自治数据卫士服务实例(本地或跨区域),额外定价为您在创建或显式缩放主服务实例时预留的 ECPU 或 OCPU 数,无论是否启用自动缩放。Autonomous Data Guard 备用服务实例上不会在主服务实例上发生与自动缩放相关的 ECPU 或 OCPU 使用情况。
区间配额如何影响 CPU 管理
通常,当您创建或扩展自治 AI 数据库时,基于专用 Exadata 基础结构的 Oracle Autonomous AI Database 满足您的请求的能力仅取决于整个部署中单个 CPU 池中未分配的 CPU 的可用性。
但是,您可以使用 Oracle Cloud Infrastructure 的区间配额功能按区间进一步限制可用于创建、手动缩放和自动缩放每个工作负载类型(自治 AI 数据湖仓或自治 AI 事务处理)的自治 AI 数据库的 CPU 数量。
简而言之,您可以通过创建 set、unset 和 zero 策略语句来使用区间配额功能,以限制给定区间中给定资源的可用性。有关详细信息和说明,请参阅区间限额。
VM 集群节点如何影响 CPU 管理
上面关于 CPU 管理和分配状态的讨论指出,您可以通过在预配 AVMC 资源时选择每个节点的 CPU 计数来创建多个自治 Exadata VM 集群 (AVMC) 资源。
本节将详细介绍 Oracle Cloud Infrastructure 如何将自治 AI 数据库放置在 VM 集群节点中,以及此类放置对自动缩放和并行处理的后果。
以下属性确定自治 AI 数据库在多个节点上的放置时间和方式:
-
拆分阈值:CPU 值,超过此值,Oracle Cloud Infrastructure 可跨多个节点打开自治 AI 数据库。对于 ECPU,默认拆分阈值为 64,对于 OCPU,默认拆分阈值为 16,但如果创建的 VM 集群的 CPU 节点计数低于默认值,则默认拆分阈值会覆盖到 VM 集群节点计数大小。您还可以在预配自治容器数据库 (Autonomous Container Database,ACD) 时使用“Split Threshold(拆分阈值)”属性显式设置拆分值。
创建的 CPU 值小于拆分值的自治 AI 数据库将在集群中的一个节点上打开,创建时 CPU 值大于拆分阈值的数据将在多个节点上打开。
-
假设您在 AVMC 中创建具有默认拆分阈值(64 个 ECPU)的 ACD,每个节点具有两个节点和 40 个 ECPU。由于 40 小于 64,因此 CPU 要求大于 40 的任何自治 AI 数据库都将在多个节点之间拆分并打开,从而允许在这些节点之间进行 DML 请求。但是,如果 AVMC 创建时有两个节点,每个节点 80 个 ECPU,则要求 ECPU 大于 64 的任何数据库都会拆分并在多个节点间打开。
-
假设您在 VM 集群中创建一个 ACD,每个节点具有两个节点和 40 个 ECPU,并且将拆分阈值显式设置为更小的值(例如 20 个 ECPU)。CPU 需求大于 20 的任何自治 AI 数据库都将在多个节点上拆分并打开,CPU 需求小于 20 的数据库将在单个节点上打开。
如果将拆分阈值设置为比默认值小得多的数字,则在多个节点上打开较小的 CPU 计数会增加数据库的机会,前提是它们的 CPU 计数大于设置的拆分值。每当创建数据库或将其缩放到大于此拆分值的大小时,它就会在多个节点上打开。当希望数据库在多个节点上打开以控制节点出现故障或计划内维护时的性能降级时,这非常有用。如果数据库在较大的 RAC 集群中的多个节点之间拆分,如果任一节点出现故障或发生调度维护,则可以继续获得更高的性能,而不是降低到 50% 的性能配置文件。
-
假设您在具有两个节点和 40 个 ECPU 的 AVMC 中将拆分阈值显式设置为比默认值高得多(例如 80 个 ECPU)。CPU 需求大于 40 的任何自治 AI 数据库都将在多个节点之间拆分和打开,CPU 需求小于 40 的数据库将在单个节点上打开。
将拆分阈值设置为比默认值高得多的值将导致数据库 DML 停留在单个 RAC 节点上,并消除集群等待争用的机会。
-
手动缩放自治 AI 数据库时,新的 CPU 值将应用于现有拆分模型。也就是说,如果新值小于拆分阈值,它将在一个节点上打开,如果该值大于拆分阈值,它将在多个节点上打开。
-
-
分配关联性:确定自治 AI 数据库在超过拆分阈值后将打开的节点数。
例如,假设您创建了一个 AVMC 资源,每个节点具有 4 个节点和 80 个 ECPU,并且在此 AVMC 中创建了一个 ACD,数据库 Split Threshold 设置为 64。创建 ECPU 要求为 120 的自治 AI 数据库将在多个节点之间拆分并打开数据库,大小为 120 大于 64(拆分阈值)。
-
如果将分发关联性设置为最小节点数,Oracle Cloud Infrastructure 将尝试在 2 个节点上创建数据库,每个节点上有 60 个 ECPU。如果这是不可能的,它将拆分为 3 个节点,每个节点 40 个 ECPU。如果这也是不可能的,Oracle Cloud Infrastructure 将尝试在 4 个节点上打开数据库,每个节点 30 个 ECPU。
-
如果您指定与最大节点数的分发关联,Oracle Cloud Infrastructure 将尝试创建跨所有 4 个节点(每个节点 30 个 ECPU)拆分的数据库。如果这是不可能的,它将拆分为三个节点,每个节点 40 个 ECPU。如果这也是不可能的,Oracle Cloud Infrastructure 将尝试在 2 个节点上打开数据库,每个节点 60 个 ECPU。
-
-
节点故障转移保留 (%) :在 AVMC 中为本地化故障和维护事件预留的相邻节点(数据库软件存在但未打开的节点)上的 CPU 数。节点故障转移保留应用于非拆分数据库部署。默认情况下,存在 50% 的保留,这意味着在故障事件或维护期间,您将继续运行,但处于分配的 CPU 的 50%。
-
对于利用率非常低的非关键数据库或数据库,您可以将节点故障转移保留设置为更小的值,以便最终可以在专用 Exadata 基础结构上创建和合并更多数据库。
-
对于可接受维护期间停机的开发环境和数据库,可以将此值设置为零。
-
在某种程度上,还可以通过使用拆分阈值和分配关联来确保数据库拆分到 2 个以上的节点,从而控制节点故障转移保留。考虑将自治 AI 数据库拆分为 4 个节点的方案。通过在维护活动进行期间以滚动方式一次删除一个节点,您始终有 3 个节点仍在运行并占用流量,从而有效地保留了 75% 的性能,而不是通常的 50%。对于更大的集群,您可以进一步推动此保留,例如,8 节点集群上的 87.5% 保留。
-
自治 AI 数据库的 CPU 分配如何分布在 VM 集群节点中会影响以下操作:
-
自动缩放:
-
对于不可并行化的 DML,单个 VM 集群节点内可能会自动扩展;如果 DML 可并行化,则可以在 VM 集群节点之间自动扩展。
-
具有不可并行化查询的多个并发会话可以路由到集群中的所有节点,从而有效地允许跨多节点数据库中的所有节点进行自动缩放。
-
-
并行处理:
- SQL 语句的并行处理发生在已打开的自治 Exadata VM 集群节点内,首先在单个节点内,然后发生在相邻的打开节点中,如上所述,这取决于自治 Exadata VM 集群的大小。
根据每个节点上的资源利用率;并非所有可用 CPU 值都可用于预配或扩展自治 AI 数据库。例如,假定您在 AVMC 级别有 20 个 CPU 可用,但并非 1 到 20 个 CPU 的所有值都可用于预配或扩展自治 AI 数据库,具体取决于节点级别的资源可用性。可用于预配或缩放自治 AI 数据库的 CPU 值列表称为可预配 CPU 。
当您尝试从 OCI 控制台预配或扩展自治 AI 数据库时,“CPU(CPU)”字段将为您提供包含可预配 CPU 列表的下拉列表。或者,可以使用以下 API 获取临时 CPU 值列表:
-
GetAutonomousContainerDatabase 返回可用于在给定自治容器数据库中创建新的自治 AI 数据库的可预配 CPU 值列表。有关详细信息,请访问 GetAutonomousContainerDatabase 。
-
GetAutonomousDatabase 返回可用于扩展给定自治 AI 数据库的可预配 CPU 值列表。有关详细信息,请访问 GetAutonomousDatabase 。