Oracle 计划将许多数据库迁移到新的RACs

你好，

我们计划将90多个Oracle数据库从独立服务器转移到3个新的RACs中。

问题是如何使三组数据库在任何时候 (概率上) 达到最低的CPU-I/O使用率。

这些组应该由时间上有互补负载的数据库组成。

我们认为也许我们可以围绕度量标准 “每秒数据库时间” (V $ syssmetric_history) 进行匹配，分析它在工作时间，工作时间以外，一周，一个月等的每个db的行为。

根据https://www.oracle.com/technetwork/database/manageability/db-perf-tuning-ow08-131582.pdf

'每秒数据库时间' 不包括 “每秒背景时间”

我们应该在分析中包括 “每秒背景时间” 吗？

事情是 “每秒背景时间” 的METRIC_UNIT不是一个时间单位，它有点令人困惑 (“活动会话”)，我们应该如何解释这一点？

你对此有什么建议吗？，任何其他指标 (或指标的计算)？

如果您知道有关此任务或容量管理的任何分步指南，我们将不胜感激。

谢谢。

我不会太担心背景时间，因为它 (几乎) 总是前景时间的副产品 (例如，您的重做编写者只是忙于，因为前景正在进行更改)

因此，如果您根据前台会话进行分配，则很可能会在后台开销方面实现相同的目标。

对我来说，我几乎完全基于我的计划平均活动会话，因为即使某些会话是CPU密集型的，而其他会话是I/O密集型的，最终 (给定现代磁盘阵列) 这些I/O密集型的将在CPU上变得沉重。因此，我将 “活动会话” 视为 “CPU刻录机”，并使用它来决定我想在哪里拆分我的工作负载 (无论是基于总负载，还是他们在一天/周/等的特定时间的负载)。

但是我要补充一点-它不只是 * 关于负载，除非您拥有的每个应用程序在以下方面都有相同的要求

-正常运行时间
-软件版本依赖关系
-RPO/ro
-维护/修补循环等

确保您将所有内容都考虑在内，以便提出最能满足所有这些业务目标的策略。

并且不要忘记 (假设您将使用可插拔数据库)，在最坏的情况下，您可以从一台服务器上拔下数据库，并在需要时将其重新定位到另一台服务器。