【每日一摩斯】-Troubleshooting: High CPU Utilization (164768.1) - 系列4

Jobs (CJQ0, Jn, SNPn)

Job进程运行用户定义的以及系统定义的类似于batch的任务。检查Job进程占用大量CPU资源的方法,就像检查用户进程一样。

可以根据以下视图检查Job进程运行的状态:DBA_JOBS_* , DBA_SCHEDULER_*, DBA_AUTOTASK_*。

这些进程可能会消耗大量的CPU资源,因为他们无限循环地查询job队列。

Note: 8531434.8 Bug 8531434 - Solaris: Excessive CPU by MMNL/CJQ0 when running multiple instances and cpus

Advanced Queuing (AQ, QMN)

AQ进程通常通过表来发送和接收消息。因为表需要purge或重组织,或者其它与AQ相关的事情,导致CPU资源的大量消耗。

Note 305662.1 Master Note for AQ Queue Monitor Process (QMON) 

Note:271855.1 Procedure to manually Coalesce all the IOTs/indexes Associated with Advanced Queueing tables to maintain Enqueue/Dequeue performance, reduce QMON CPU usage and Redo generation

Parallel Query (Pnn)

并行查询进程适合于某些特殊情况,这些情况下确实会消耗大量的CPU资源。然而,Oracle建议我们确保系统以最优的方式建

立。并行查询选项在数据仓库类型的环境下是最佳的选择,这种情况下仅有一小部分用户会运行这些查询。

Note:203238.1 Using Parallel Execution.

时间: 2024-09-22 08:46:53

【每日一摩斯】-Troubleshooting: High CPU Utilization (164768.1) - 系列4的相关文章

【每日一摩斯】-Troubleshooting: High CPU Utilization (164768.1) - 系列1

这篇文章的目的是帮助寻找消耗CPU较高的Oracle进程. 高CPU应用不一定就是问题,或者说系统资源正在被充分利用.然而,如果CPU使用持续高,但系统负载低.系统性能差,那么就应该调查下CPU高使用率的原因.特别地,如果一个或多个进程持续是以其它进程为代价,持续消耗CPU资源,那么就应该调查这个CPU进程.除了为解决一些问题来收集的信息,几乎没有办法停止这些进程消耗CPU资源.另一方面,我们可以防止这种情况的发生.Oracle提供了两种方法限制个人用户使用的CPU资源: Profiles  N

【每日一摩斯】-Troubleshooting: High CPU Utilization (164768.1) - 系列2

当一个进程使用大量CPU资源时,需要查找哪些线索呢? 哪些进程在使用CPU? 后台进程 Oracle用户进程 和Oracle无关的操作系统进程 僵尸进程 后台进程: PMON: 当清理进程或在监听注册时,PMON进程占用CPU较高资源的主要原因可能是某个BUG. SMON: SMON进程负责空间整合与交易恢复,如果使用的是字典管理表空间,那么可能会产生巨大的消耗. 字典管理表空间中,如果一个包含很多extent区的大表被drop或truncate,SMON能让数据库hang住. 从9i开始,本地

【每日一摩斯】-Troubleshooting: High CPU Utilization (164768.1) - 系列3

LGWR & DBWR 这两个进程通常是和IO相关的,但是当存在操作系统问题,这两个进程可能"spin(等待)"直到IO操作完成.这种等待是一种CPU操作.异步IO操作的缓慢或失败也能证明它们是高CPU消耗的. 如果LGWR间歇地占用100%的CPU资源,那么异步输入输出AIO配置应该重新检查.作为一种临时性的方法,可以设置下面的参数防止LGWR出现等待的现象: _lgwr_async_io=false 这个参数可以关闭LGWR的异步输入输出. Note: 813473.1 L

【每日一摩斯】-Troubleshooting: High CPU Utilization (164768.1) - 系列5

Oracle(用户)进程 以下这些操作都是需要消耗大量CPU资源的:解析大型查询,存储过程编译或执行,空间管理和排序. 下面这几篇文章可以帮助采集关于使用高CPU资源的进程的更多信息: Note:352648.1 How to Diagnose High CPU Usage Problems to the Module Level  Note:452358.1 How to Collect Diagnostics for Database Hanging Issues 补充:Oracle用户进程

【每日一摩斯】-Troubleshooting: High CPU Utilization (164768.1) - 系列6

如果问题是一个正运行的缓慢的查询SQL,那么就应该对该查询进行调优,避免它耗费过高的CPU资源.如果它做了许多的hash连接和全表扫描,那么就应该添加索引以提高效率. 下面的文章可以帮助判断查询的问题: Note:215187.1 SQLT (SQLTXPLAIN) - Tool that helps to diagnose SQL Note:199083.1 Master Note: SQL Query Performance Overview 实时SQL监控是11g的一个新特性,它能监控正运

【每日一摩斯】-Shared Pool优化和Library Cache Latch冲突优化 (1523934.1)-系列4

CURSOR_SHARING 参数 (8.1.6 以上)        这个参数需要小心使用.如果它被设为FORCE,那么Oracle会尽可能用系统产生的绑定变量来替换原来SQL中的literals部分.对于很多仅仅是literal不一样的相似的语句,这会让它们共享cursor.这个参数可以在系统级别或者session级别动态设置: ALTER SESSION SET cursor_sharing = FORCE; 或者 ALTER SYSTEM SET cursor_sharing = FOR

【每日一摩斯】-Shared Pool优化和Library Cache Latch冲突优化 (1523934.1)-系列6

使用SQL 查看Shared Pool问题        这一章节展示了一些可以用来帮助找到shared pool中的潜在问题的SQL语句.这些语句的输出最好spool到一个文件中. 注意:这些语句可能会使latch竞争加剧,我们在上面的"使用 V$ 视图 (V$SQL 和 V$SQLAREA)" above. 查找literal SQL SELECT substr(sql_text,1,40) "SQL",                count(*) ,  

【每日一摩斯】-Shared Pool优化和Library Cache Latch冲突优化 (1523934.1)-系列1

什么是Shared Pool?        Oracle的实例主要包括共享内存(主要是SGA,还有PGA)和Background Processes,其中SGA中又包括了Shared Pool.Buffer Cache.Redo Log Buffer以及其它一些内存区.        Oracle在SGA的一个特定区域中保留SQL语句.Package是.对象信息以及其它一些内容,这就是Shared Pool.这个共享内存区域是由一个复杂的cache和heap manager 构成的.它需要解决

【每日一摩斯】-Shared Pool优化和Library Cache Latch冲突优化 (1523934.1)-系列2

下面来谈一谈系列1中讲到的Literal SQL和Shared SQL的比较. 首先是Literal SQL: 在有完整的统计信息并且SQL语句在predicate(限定条件)中使用具体值时,基于成本的优化器 (CBO)能工作的最好.比较下面 的语句: SELECT distinct cust_ref FROM orders WHERE total_cost < 10000.0; 和 SELECT distinct cust_ref FROM orders WHERE total_cost <