Skip to main content
NetApp database solutions
简体中文版经机器翻译而成，仅供参考。如与英语版出现任何冲突，应以英语版为准。

Oracle 数据库部署需要考虑的因素

贡献者 kevin-hoke
PDF

公共云为计算和存储提供了许多选择，使用正确类型的计算实例和存储引擎是数据库部署的良好起点。您还应该选择针对 Oracle 数据库优化的计算和存储配置。

以下部分介绍在具有Azure NetApp Files存储在 Azure 虚拟机实例上的 Azure 公有云中部署 Oracle 数据库时的主要注意事项。

VM 类型和大小

选择正确的虚拟机类型和大小对于公共云中关系数据库的最佳性能非常重要。 Azure 虚拟机提供了多种可用于托管 Oracle 数据库工作负载的计算实例。请参阅 Microsoft 文档"Azure 中的虚拟机大小"适用于不同类型的 Azure 虚拟机及其大小。一般来说， NetApp建议使用通用 Azure 虚拟机来部署中小型 Oracle 数据库。对于部署更大的 Oracle 数据库，内存优化的 Azure VM 是合适的。有了更多的可用 RAM，就可以配置更大的 Oracle SGA 或智能闪存缓存来减少物理 I/O，从而提高数据库性能。

Azure NetApp Files作为连接到 Azure 虚拟机的 NFS 挂载，可提供更高的吞吐量，并通过本地存储克服存储优化的 VM 吞吐量限制。因此，在Azure NetApp Files上运行 Oracle 可以减少可许可的 Oracle CPU 核心数量和许可成本。看"TR-4780：Microsoft Azure 上的 Oracle 数据库"，第 7 节 — Oracle 许可如何运作？

其他需要考虑的因素包括：

  • 根据工作负载特征选择正确的 vCPU 和 RAM 组合。随着虚拟机上的 RAM 大小增加，vCPU 核心的数量也会增加。由于 Oracle 许可费用是根据 vCPU 核心数量收取的，因此在某个时候应该达到平衡。

  • 向虚拟机添加交换空间。默认的 Azure VM 部署不会创建交换空间，这对于数据库来说不是最佳的。

Azure NetApp Files性能

Azure NetApp Files卷是从容量池中分配的，客户必须在其Azure NetApp Files存储帐户中配置该容量池。每个容量池的分配如下：

  • 达到定义整体性能能力的服务水平。

  • 该容量池最初配置的存储容量或分层。定义每个配置空间的总体最大吞吐量的服务质量 (QoS) 级别。

服务级别和初始配置的存储容量决定了特定 Oracle 数据库卷的性能级别。

1.Azure NetApp Files的服务级别

Azure NetApp Files支持三种服务级别：Ultra、Premium 和 Standard。

  • *超级存储。*此层级每分配 1TiB 卷配额可提供高达 128MiBps 的吞吐量。

  • *高级存储。*此层级每分配 1TiB 卷配额可提供高达 64MiBps 的吞吐量。

  • *标准存储。*此层级每分配 1TiB 卷配额可提供高达 16MiBps 的吞吐量。

2.容量池和服务质量

每个所需的服务级别都与配置容量的成本相关，并包括定义配置空间的总体最大吞吐量的服务质量 (QoS) 级别。

例如，具有高级服务级别的 10TiB 预配置单容量池可为此容量池中的所有卷提供 10x 64MBps 的总可用吞吐量，即 640MBps，具有 40,000 (16K) IOPs 或 80,000 (8K) IOPs。

最小容量池大小为 4TiB。您可以根据工作负载需求的变化，以 1TiB 为增量更改容量池的大小，以管理存储需求和成本。

3.计算数据库卷的服务级别

Oracle 数据库卷的吞吐量限制由以下因素组合决定：卷所属容量池的服务级别和分配给该卷的配额。

下图显示了如何计算 Oracle 数据库卷的吞吐量限制。

该图描述了应用于三个容量层级以确定总吞吐量的方程式。

在示例 1 中，来自具有高级存储层的容量池的卷分配了 2TiB 的配额，其吞吐量限制为 128MiBps（2TiB * 64MiBps）。无论容量池大小或实际容量消耗如何，此场景都适用。

在示例 2 中，来自具有高级存储层的容量池的卷分配了 100GiB 的配额，其吞吐量限制为 6.25MiBps（0.09765625TiB * 64MiBps）。无论容量池大小或实际容量消耗如何，此场景都适用。

请注意，最小卷大小为 100GiB。

存储布局和设置

NetApp建议采用以下存储布局：

  • 对于小型数据库，所有 Oracle 文件使用单卷布局。

    该图描绘了三个数据库（DB1、DB2 和 DB3），每个数据库都包含单个容量池内的数据文件、重做日志、存档日志和控制文件。

  • 对于大型数据库，建议的卷布局是多个卷：一个用于 Oracle 数据和重复控制文件，一个用于 Oracle 活动日志、存档日志和控制文件。 NetApp强烈建议为 Oracle 二进制文件分配一个卷而不是本地驱动器，以便数据库可以重新定位到新主机并快速恢复。

    该图描绘了两个数据库，每个数据库有两个卷。第一个卷包含数据文件，而每个数据库的第二个卷包含重做日志、存档日志和控制文件。全部都在一个容量池内。

NFS 配置

Linux 是最常见的操作系统，包含原生 NFS 功能。 Oracle 提供了原生集成到 Oracle 中的直接 NFS (dNFS) 客户端。 Oracle dNFS 绕过操作系统缓存并支持并行处理以提高数据库性能。 Oracle 已支持 NFSv3 超过 20 年，Oracle 12.1.0.2 及更高版本支持 NFSv4。

通过使用 dNFS（自 Oracle 11g 起可用），在 Azure 虚拟机上运行的 Oracle 数据库可以比本机 NFS 客户端驱动更多的 I/O。使用NetApp自动化工具包的自动化 Oracle 部署会自动在 NFSv3 上配置 dNFS。

下图演示了使用 Oracle dNFS 的Azure NetApp Files上的 SLOB 基准。

该图表明显表明 dNFS 比 KNFS 改善了 DB 顺序文件延迟（毫秒）。

其他需要考虑的因素：

  • TCP 插槽表相当于 NFS 中的主机总线适配器 (HBA) 队列深度。这些表控制任意时间同时存在的未处理 NFS 操作的数量。默认值通常为 16，数值太低无法实现最佳性能。在较新的 Linux 内核上会出现相反的问题，它会自动将 TCP 插槽表限制增加到使 NFS 服务器充满请求的级别。

    为了获得最佳性能并防止出现性能问题，请将控制 TCP 槽表的内核参数调整为 128。

    sysctl -a | grep tcp.*.slot_table

  • 下表提供了针对 Linux NFSv3 单个实例的推荐 NFS 挂载选项。

    下表显示了以下文件类型、控制文件、数据文件、重做日志、ORACLE_HOME 和 ORACLE_BASE 的详细 NFS 挂载选项。

备注 在使用 dNFS 之前，请验证是否安装了 Oracle Doc 1495104.1 中描述的补丁。 NetApp针对 NFSv3 和 NFSv4 的支持矩阵不包含特定的操作系统。支持所有遵循 RFC 的操作系统。在在线 IMT 中搜索 NFSv3 或 NFSv4 支持时，请勿选择特定的操作系统，因为不会显示任何匹配项。常规策略隐式支持所有操作系统。