【每日一摩斯】-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的一个新特性,它能监控正运行的SQL性能。

Note.1229904.1 Real-Time SQL Monitoring in 11g

其它的跟踪技术也可能是有用的,用于判断一个进程是否需要继续使用高CPU资源,分析原因。

Note:376442.1 How To Collect 10046 Trace (SQL_TRACE) Diagnostics for Performance Issues

总结:

SQL调优其实是一个很复杂的事情,有时表象仅仅是慢,但其真正的原因可能是多样性的,可能是SQL语句的问题,可能是数据库具体参数配置的问题,也可能是操作系统资源争用的问题,这样的问题必须具体问题具体分析,没有一个统一的规则,但至少对于每一类问题有一些可参考的判断方法,可能直接看这些印象不会太深,真实处理这样的问题往往更有意义,当然不是每次都有这样的机会,那就创造机会或寻找机会,总之如果想学,就一定有方法可以学到的。

时间: 2024-11-15 09:22:30

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

【每日一摩斯】-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) - 系列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/C

【每日一摩斯】-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用户进程

【每日一摩斯】-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 <