select * from v$osstat;
user：user level（应用）的CPU占用情况
nice：加入nice优先级的user level的CPU占用情况
sys：system level（内核）的CPU占用情况
idle：空闲的CPU资源情况
--查看每个Session的CPU利用情况：
select ss.sid,se.command,ss.value CPU ,se.username,se.program
from v$sesstat ss, v$session se
where ss.statistic# in
( select statistic#
from v$statname
where name = 'CPU used by this session' )
and se.sid= ss.sid
and ss.sid>6 order by CPU desc ;
这里面包含了很多东西，可以使用select * 来看看。
--比较一下哪个session的CPU使用时间最多，然后查看该Session的具体情况：
select s.sid, s.event, s.MACHINE,s.OSUSER,s.wait_time, w.seq#, q.sql_text
from v$session_wait w, v$session s, v$process p, v$sqlarea q
where s.paddr=p.addr and
s.sid =&p and
s.sql_address = q.address;
根据上一个sql判断出来的SID，进行查询。
得出来的结果：
Oracle与CPU资源
Oracle数据库与运行在同一台服务器上的其他所有软件共享CPU资源。如果CPU处理能力不足，减少Oracle或者非Oracle程序的CPU消耗可以改善服务器上所有进程的性能。
如果机器上所有CPU都繁忙，这些进程将排队等待使用CPU。由于进程需要等待CPU资源，因而这些进程所形成的队列又被称作运行队列。CPU越忙，进程在运行队列中等待的时间就越长。处在队列中的进程并不做任何工作，运行队列变长，响应时间就会下降。
可以使用操作系统标准监控工具来检查主机上CPU的使用情况。
对CPU的利用率进行调优实质上就是对每个单独的任务进行调优：它将减少完成任务所需要的命令数量，并/或者减少要执行的认为数量。通过负载均衡，SQL调优，以及改进应用程序的设计等方式来具体完成CPU调优工作。从事这样的调优工作需要你深入理解这些任务的目的以及它们被执行的方式。
在前面已提到，关于Oracle数据库所有调优问题的深入讨论不是本书的主题。但是，有一些常见的任务经常会导致CPU被过度使用。如果在数据库中遇到CPU资源缺乏的情况，可能需要考虑一下因素：
糟糕的SQL语句
糟糕的SQL语句是导致性能问题的头号因素。Oracle数据库总是尝试优化客户提交的SQL语句。如果在客户应用程序中的SQL语句编写得很糟糕，这个时候即便是Oracle采取了最佳的优化方案，也无济于事，Oracle将会消耗比实际需要还多的资源来执行该SQL语句。由于调整SL需要深入理解Oracle的工作原理以及应用程序的需求，因而整个过程困难而又费时。早期的检查工作能够发现底层数据库的设计问题，从而会导致修改表结构和索引等。在Oracle数据库10g之前，改变SQL语句需要重新对之进行测试，以及重新部署应用程序。
Oracle数据库10g引入了SQL调优顾问工具，该工具不仅可以识别编码槽糕的SQL语句，还可以创建优化器规划来解决这类问题，并采用改进后的规划来代替标准的优化方案。有了这样的工具，可以在不修改任何代码的情况下改善那些糟糕的SQL语句的性能。Oracle数据库11g中的SQL顾问工具包含了SQL调优顾问，SQL访问顾问，以及分区顾问这三个组件的功能。
Oracle数据库11g能够自动侦测工作负荷最大的SQL查询操作，并能够在适当的情况下创建SQL轮廓信息来提高它们的性能。另外，这个特性还能够为新索引的创建提供建议，进而提高这些语句的性能。
Oracle数据库11g还具有跟踪SQL语句执行计划变更的功能；第4章曾经对此进行过描述。它的优化器能够维护执行计划的历史信息，当新的计划被检测到，优化器会在使用旧计划的同时评估新计划的性能。一旦优化器发现新计划能够提供同样的性能，它就会用新计划替换旧计划。这个特性与糟糕的SQL语句并没有直接的关系，但是它关系到计划变更的各种后果，这会导致难以预料的性能衰退。
过多的解析
正如"SQL语句的内存"一节中讨论的那样，Oracle在执行SQL语句之前必须对之进行解析。解析工作是CPU密集型的，其中包括对照数据字典来检查引用的表和列是否有效。通过复杂的算法和计算来估算语句所有执行计划的开销，从而得到最佳的执行计划。如果语句中没有绑定变量（在第8章中讨论），数据库必须解析它受到的每一条语句。这种额外的没有必要的解析是导致性能下降的主要原因之一。另一个常见的原因就是共享内存池太小，这个在"共享内存池" 一节中已经讨论过。记住，通过使用存储概要可以避免创建执行计划；第4章曾经介绍过存储概要。而且，对应Oracle 9i，你还可以通过编辑提示来构建一个存储概要。前面也提到过，Oracle数据库11g具有缓存完整结果集的功能，它可以将相同查询重复执行的影响降到最低。
数据库的工作负荷
当应用程序设计良好并且数据库运行在最佳状态的时候，你可能遇到的问题就是由于请求的工作量过大而没有足够多的CPU资源来处理。这种CPU资源缺乏可能是由于某一个数据库工作负荷过大而导致（如果该数据库所在的机器为专用服务器），也可能是由于运行在一台服务器上的多个数据库总的工作负荷过大而导致。在容量设计的时候低估CPU资源的使用情况，这是一个长期存在的问题。不幸的是，对某一级操作的CPU资源的准确估计，需要详细深入的分析每个事务所耗费的CPU资源总量，以及每分钟或每秒钟系统需要处理的事务数量，而其要根据高峰负荷和平均负荷进行估计。大多数的组织机构并没有花足够多的时间和资源通过分析系统和制作原型来回答这些问题。这个时候我们就会明白为什么CPU资源短缺问题如此常见，为什么解决这种问题最常见的方案就是简单的添加更多的 CPU一直到这种问题消失为止。实时应用程序集群以及Oracle网格正在做各种努力试图让管理人员能够更加容易的提高CPU的马力。
非数据库工作负荷
并不是所有的组织机构都有能力为每个Oracle数据库都配置一台专用的主机来保证它们能够占有足够的CPU资源。可以借助操作系统工具来查找主机上最大的CPU资源消耗者。你可能会发现非Oracle进程消耗了大部分的CPU资源，并且严重的影响数据库性能。
扫一扫
1012
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
