我正在使用oracle 11g，我有一个在Spring框架中编码的应用程序。一旦我在安装了Linux的Sun fire 4170上配置数据库，机器的CPU利用率大约为80-100％，然而，当我将相同的数据库转移到安装了Unix OS的Sun M3000服务器（据称功能更强大的机器）时，应用程序性能变得更好down和CPU利用率保持在90-100％。我无法弄清楚它是否正在进行这样的利用或其数据库设计的应用程序。 补充说，数据库不是关系型的;事情由应用程序处理。
答案 0 :(得分：7)
你当然可以在intertubes上找到一些有趣的意见。
Oracle没有真正的服务器 建筑（其他人拥有它）。
而不是执行经典服务器 任务，例如多线程， 并行缓存数据页面 处理（将查询拆分为多个 设备）等本身，它使用 o / s做所有这些。这意味着 每个用户进程（PL / SQL连接） 有一个unix进程; 1000个用户 全部意味着1000个unix进程 竞争相同的资源。
您可能会注意到Oracle已经
值得注意的是，即使所说的都是正确的而不是错误的，它实际上并不能帮助您确定根本原因。
特别值得注意的是，因为它使用 文件系统文件（不是原始的 分区），“缓存”是 在外面，它严重依赖（并且是 对文件系统非常敏感 您已设置的缓存。同样， Oracle需要大量的资源 这些过程的记忆。
Oracle当然可以再次使用原始分区，可以追溯到上一个千禧年，而且如果你想在数据库中缓存 - 使用PerformanceDBA已经忘记的缓冲区缓存 - 并绕过文件系统缓存这个功能在所有当前文件系统上都可用。 Oracle还在ASM中提供了自己的组合文件系统/卷管理器，如果您愿意，可以使用它。
Oracle也有很好的仪表化（如果你有权访问dtrace，那么是solaris）并且当然可以告诉你哪些会话，进程等正在使用CPU，应用程序在数据库中花费的时间是由（down）如果您愿意，可以单独阻止读取时间，因此非常容易进行分析。我建议你在http://www.method-r.com/downloads/cat_view/38-papers-and-articles查看关于性能的清晰思考，并由世界顶级Oracle性能专家撰写。如果您可以访问Oracle诊断程序包，则首先检出所有ADDM报告，然后检查AWR报告是否有利可图。
答案 1 :(得分：5)
试图在这里避免火焰战争。
我应该从我对PerformanceDBA中有关服务器架构的评论的回答中更清楚地分离出我的回答的“如何找出”部分。我分享了斯蒂芬妮对弹簧框架的怀疑，但如果没有适当的范围测量证据，就没有必要指责环境的任何特定属性，这只是特别的偏见。幸运的是，内置在oracle内核中的工具允许您跟踪然后分析慢速会话以确定问题的确切位置。所以我会做以下事情：
1）启用代表会话的跟踪（您可以使用dbms_monitor包）。 2）还收集涉及gather_plan_statistics提示的语句的执行计划。 3）使用适当的配置文件（tkprof，orasrp，method-r profiler）按时间分析跟踪文件
调查对响应时间顺序的贡献中的问题陈述。
如果您无法执行上述操作，那么您可以使用ADDM和/或AWR（如果我最初建议的许可）或statspack（如果未获得诊断包许可）。 ADDM自然会集中在时间消费者身上，我建议如果你被迫沿着statspack路线做同样的事情。
答案 2 :(得分：3)
M3000当然是一台功能更强大的机器，但它更适合真正的服务器。带有超线程的X4170更适合文件服务器。
我不太确定。有任何数据支持该声明吗？
M3000有一个SPARC64 VII处理器，有4个核心（tech specs），而X4170有1个或2个Intel 5500“Nehalem-EP”处理器，每个处理器有4个核心（tech specs）。我知道，即使是单处理器的Nehalem-EP系统，我也会期待比M3000更多的东西。显然数据会随着工作量的不同而略有不同，但我知道我会把钱放在哪里。