在面对Oracle数据库上本身提供众多复杂和复杂的资源管理器和计划时，我们往往会感到无所适从。然而，导致性能问题的一个常见原因是未充分理解和利用数据库资源管理的功能。因此，本文旨在解锁Oracle资源管理的实用性，将焦点放在CPU和内存控制方面，通过MOS中参考文件整理出简洁明了的解释和示例SQL来帮助您更好地管理数据库资源。
1 关于资源管理器
Oracle提供的Resource Manager可以更好的控制数据库对硬件资源的分配使用权。我们先聊下数据库在运行过程中会碰到什么问题，Oracle通过Resource Manager能做些什么？
当将数据库资源分配决策交给操作系统时，可能会遇到以下与工作负载管理相关的问题：
- 过度开销：当数据库服务器进程数量较多时，操作系统在这些进程之间进行上下文切换，导致过度的开销。
- 效率低下的调度：操作系统在持有锁时撤销数据库服务器的调度，这是低效的。
- 资源分配不当：操作系统平均分配资源给所有活动进程，不能优先考虑一个任务而忽略其他任务。
- 无法管理数据库特定的资源，如并行执行服务器和活动会话。
Resource Manager通过允许数据库更好地控制硬件资源的分配来解决这些问题。Resource Manager允许您根据会话属性将会话分类为不同的组，并以最优的方式为这些组分配资源，以优化您的应用环境中的硬件利用率。使用Resource Manager，您可以：
- 保证某些会话在系统负载和用户数量上都能获得一定的最小CPU时间。通过将CPU时间的百分比分配给不同的用户和应用程序来分配可用的CPU。
- 限制由一组用户执行的任何操作的并行度。管理并行语句在并行语句队列中的顺序。可以将关键应用程序的并行语句排在低优先级用户组的并行语句之前。限制一组用户可以使用的并行执行服务器数量。
- 创建一个活动会话池。一个活动会话池由一组用户允许同时活动的最多会话数量组成。超过最大数量的会话将进入排队状态等待执行，但您可以指定一个超时时间，在此之后排队作业将被终止。活动会话池限制了正在竞争资源的会话总数，从而使活动会话能够更快地进行。
- 监视资源的使用情况，自动记录关于资源使用的统计信息。您可以使用实时SQL监控和Resource Manager动态性能视图（
V$RSRC_*视图）来查看这些统计信息。 - 限制每个属于某个用户组的会话使用的PGA内存的数量。
- 以可量化方式管理运行超出指定资源限制的会话或调用：
- 预防优化器预估运行时间超过指定限制的操作的执行。 ...
为实现上述的功能，Oracle的Resource Manager总共包括如下组件：
- 资源消费者组(消费者组)是用户会话的集合，这些用户会话根据其处理需求分组在一起。
- 资源计划指令：资源管理器根据属于当前活动资源计划的资源计划指令集将资源分配给消费者组。
- 资源计划是指令的容器，用于指定如何将资源分配给资源消费者组。
- 子计划：资源计划指令(directive)可以引用另一个资源计划，而不是引用消费者组，该计划被称为子计划。
2 实例囚笼
实例囚笼是RDBMS的一个特性，用于限制数据库实例的CPU使用。实例囚笼存对于数据库整合来说是一个很有价值的工具。
Caging设置
- 确定cpu数量
第一步是使用以下查询确定服务器上的cpu数量。在这种情况下，我们需要CPU线程的数量(而不是内核的数量)。
select value from v$osstat where stat_name = 'NUM_CPUS';
- 确定所有实例的“cpu_count”
下一步是确定服务器上的数据库实例如何共享CPU。使用Instance Caging，每个实例的cpu_count指定您希望它在任何时候使用的最大cpu数量。跨所有数据库实例的cpu_counts的总和决定了数据库实例之间的隔离程度和服务器的效率。
要在数据库实例之间实现最大程度的隔离，请使用“分区”方法。使用分区方法，cpu_counts的总和小于或等于步骤1中确定的cpu数量。对于超线程或CMT处理器，如果cpu_counts的总和小于或等于cpu数量的75%，则可以实现更多的资源隔离。分区方法适用于需要非常可预测性能的关键生产数据库。
例如，假设CPU(即CPU线程)的总数为16。使用分区方法，我们可以为数据库A设置cpu_count=8，为数据库B设置cpu_count=4，为数据库c设置cpu_count=4。cpu_counts的总和为16，等于cpu的数量。
分区方法的缺点是，一个数据库实例未使用的CPU不能被另一个数据库实例使用。因此，对于还希望获得更好的CPU利用率的非关键数据库，请使用“超额分配”方法。对于超额分配方法，cpu_counts的总和小于或等于步骤1中确定的cpu数量的3倍。
例如，对于有16个cpu的服务器，您可以使用超额分配的方法，将数据库a的cpu_count=8，数据库B的cpu_count=8，数据库c的cpu_count=8。cpu_counts的总和为24，大于cpu的数量。因此，如果所有数据库都在使用它们的全部CPU分配，就会出现一些CPU争用。
一个可接受的超额分配因子是基于所有数据库的预期总负载。例如，如果期望每个数据库始终使用其全部CPU分配，则应该对服务器进行分区。如果每个数据库预期以其全部CPU分配的50%运行，那么服务器可能会被超额分配2倍。对于许多超额分配的部署，超额分配因子3似乎是一个合理的起点。
