nj_apple_tree
- 浏览: 100110 次
- 性别:
- 来自: 上海
-
文章分类
- 全部博客 (38)
- oracle 10g logfile (1)
- oracle 性能分析 (1)
- oracle redo日志恢复 (1)
- mybatis spring (1)
- ant jar 打包 (1)
- Mybatis List列表In查询实现 (1)
- jvm 内存 (1)
- 开源 网站 Java (1)
- html (1)
- 软件开发文档 (1)
- java 数据库连接驱动 (1)
- java File (1)
- js logo 截图 (2)
- mybatis3.0 (1)
- generatorConfig (1)
- 自动生成代码 (1)
- Derby (1)
- Spring mvc (1)
- web bootstrap (1)
- oracle (1)
- PGP 加密 解密 行业标准 java (1)
- 微信小程序 应用号 (1)
- 区块链 以太坊 节点集群 (1)
最新评论
Oracle10g中如何分析响应时间
在Oracle10g中,以前版本中比较难于获取的响应时间数据将会变得非常容易获取。
在以前看来,为了尽量获得数据库的最佳性能,Oracle的DBA们和性能分析专家一直很困难获得系统以及用户会话活动的一致的响应时间数据。DBA们面临的问题一直以来包括两个方面：第一个方面是准确定位数据库或者用户会话究竟在哪里消耗了时间;第二个方面就是确定用户体验的客观性质。
在数据库中产生所有可能的行为和交互作用,这些任务都不是没有价值的。
Oracle等待接口,在之前的很早的Oracle数据库版本中开始介绍的,
对于那些知道如何使用等待接口的管理员来说这已经成为一个伟大的开始,
即使它仍然缺乏告诉DBA系统或者用户会话是否有效的处理了事务或者查询这个理想的能力。
启用和钻研跟踪文件能够存储这个级别上的详细信息,但是对于大多数超负荷工作管理大型数据库的DBA们,
这个钻研是奢侈的而耗费时间的。
幸运的是,那些将数据库升级到Oracle10g的DBA们将会发现找到主要的响应时间变得很容易,
可以允许一个非常好的图表来显示系统和会话级的响应时间数据。
很重要的一点,Oracle的ADDM提供了一个查看响应时间的方法,通过自动分析收集的统计信息,识别问题区域,
甚至可以通过Oracle企业管理器网络控制的图形界面提供建议。
此外,与我们这里讨论相关的是Oracle10g数据库的历史数据机制允许DBA们按时查看对响应时间趋势的分析,
这将有助于DBA们确定事务/系统的高峰时期,更好的定位那些拉长批处理周期和ETL作业的进程和SQL语句。
这里主要讨论用于系统、会话和SQL级别上那些历史机制的用途。
系统层的响应时间分析：
先来看看典型的几个经常问到DBA们的问题：
通常来说,数据库运行的状况如何？
用户体验感觉的平均响应时间是多少？
什么行为是最影响整个响应时间的？
上述问题在Oracle10g数据库之前对于DBA们来说是相当不好回答的,
但是如果使用了最新的Oracle10g数据库之后,这些数据信息将会很容易的被捕获到。
首先,Oracle10g数据库运行的状况如何这个问题可以通过下面的查询来获得：
select METRIC_NAME,VALUE
from SYS.V_$SYSMETRIC
where METRIC_NAME IN ('Database CPU Time Ratio','Database Wait Time Ratio')
AND INTSIZE_CSEC = (select max(INTSIZE_CSEC) from SYS.V_$SYSMETRIC);
METRIC_NAME VALUE
------------------------------ ----------------------------------
Database Wait Time Ratio 31.3499111
Database CPU Time Ratio 68.6500888
Oracle10g数据库中的V$SYSMETRIC视图中存在一些非常有用的响应时间数据,
其中两个比较重要的就是Wait Time Ratio 和Database CPU Time Ratio.
上面的查询显示了数据库中最新的关于这两个统计数据的快照,
这将有助于帮助我们确定是否数据库正在经历着一个比较高的等待百分率和瓶颈。
数据库的CPU Time Ratio是由数据库中的"database time"的数值除以CPU的数量,
"database time"定义为数据库消耗在用户级别调用所花费的时间(不包括实例的后台进程活动所消耗的时间)。
比较高的值(90%-95%以上)代表很少的 等待和瓶颈活动,因为各个系统不同,这个阀值只能作为一个一般的规则来使用。
还可以使用如下的查询来迅速查看最新一个小时的信息,看看数据库的总性能如何：
select end_time,value
from sys.v_$sysmetric_history
where metric_name = 'Database CPU Time Ratio'
order by 1;
END_TIME VALUE
----------- --------------
2007-1-24 2 3.21949216
2007-1-24 2 3.01443414
2007-1-24 2 9.75636353
2007-1-24 2 9.28581409
2007-1-24 2 43.3490481
2007-1-24 2 38.8366361
2007-1-24 2 32.0272511
2007-1-24 2 0
2007-1-24 2 22.9580733
2007-1-24 2 33.0615102
2007-1-24 2 43.1294933
可以从V$SYSMETRIC_SUMMARY视图中获得数据库整体性能效率的最大、最小和平均值：
select CASE METRIC_NAME
WHEN 'SQL Service Response Time' then 'SQL Service Response Time (secs)'
WHEN 'Response Time Per Txn' then 'Response Time Per Txn (secs)'
ELSE METRIC_NAME
END METRIC_NAME,
CASE METRIC_NAME
WHEN 'SQL Service Response Time' then ROUND((MINVAL/100),2)
WHEN 'Response Time Per Txn' then ROUND((MINVAL/100),2)
ELSE MINVAL
END MININUM,
CASE METRIC_NAME
WHEN 'SQL Service Response Time' then ROUND((MAXVAL/100),2)
WHEN 'Response Time Per Txn' then ROUND((MAXVAL/100),2)
ELSE MAXVAL
END MAXIMUM,
CASE METRIC_NAME
WHEN 'SQL Service Response Time' then ROUND((AVERAGE/100),2)
WHEN 'Response Time Per Txn' then ROUND((AVERAGE/100),2)
ELSE AVERAGE
END AVERAGE
from SYS.V_$SYSMETRIC_SUMMARY
where METRIC_NAME in ('CPU Usage Per Sec',
'CPU Usage Per Txn',
'Database CPU Time Ratio',
'Database Wait Time Ratio',
'Executions Per Sec',
'Executions Per Txn',
'Response Time Per Txn',
'SQL Service Response Time',
'User Transaction Per Sec')
ORDER BY 1;
METRIC_NAME MININUM MAXIMUM AVERAGE
---------------------------------------------- ---------- ----------
CPU Usage Per Sec 0 53.9947577 11.1603280
CPU Usage Per Txn 0 168.731666 24.8848615
Database CPU Time Ratio 0 87.1866295 35.8114730
Database Wait Time Ratio 0 90.7141859 64.1885269
Executions Per Sec 0 540.768348 114.852472
Executions Per Txn 0 1911 279.912779
Response Time Per Txn (secs) 0 3.88 0.66
SQL Service Response Time (secs) 0 0 0
User Transaction Per Sec 0 4.70183486 0.94469007
上面的查询包含了更多的详细的响应时间数据。DBA们还需要收集在系统级别上的用户通讯的平均响应时间,
上面的查询给出了需要的结果。
如果用户抱怨响应时间太慢,那么DBA就应该查看Response Time Per Txn
和SQL Service Response Time数据是否存在数据库问题。
如果响应时间不在是那么渴求,那么DBA就会想了解究竟是什么类型的用户活动让数据库的响应变得如此的慢,
在Oracle10g数据库之前,这些信息 是比较难获取的,但是现在就变得非常容易,执行如下查询：
select case db_stat_name
when 'parse time elapsed' then
'soft parse time'
else db_stat_name
end db_stat_name,
case db_stat_name
when 'sql execute elapsed time' then
time_secs - plsql_time
when 'parse time elapsed' then
time_secs - hard_parse_time
else time_secs
end time_secs,
case db_stat_name
when 'sql execute elapsed time' then
round(100 * (time_secs - plsql_time)/db_time,2)
when 'parse time elapsed' then
round(100 * (time_secs - hard_parse_time)/db_time,2)
else round(100 * time_secs/db_time,2)
end pct_time
from
(select stat_name db_stat_name,
round((value/1000000),3) time_secs
from sys.v_$sys_time_model
where stat_name not in('DB time','background elapsed time',
'background cpu time','DB CPU')),
(select round((value/1000000),3) db_time
from sys.v_$sys_time_model
where stat_name = 'DB time'),
(select round((value/1000000),3) plsql_time
from sys.v_$sys_time_model
where stat_name = 'PL/SQL execution elapsed time'),
(select round((value/1000000),3) hard_parse_time
from sys.v_$sys_time_model
where stat_name = 'hard parse elapsed time')
order by 2 desc;
DB_STAT_NAME TIME_SECS PCT_TIME
---------------------------------------------------------------- ---------- ----------
sql execute elapsed time 65.644 89.7
hard parse elapsed time 26.661 36.43
PL/SQL execution elapsed time 12.766 17.44
PL/SQL compilation elapsed time 6.353 8.68
soft parse time 2.15 2.94
connection management call elapsed time 1.084 1.48
hard parse (sharing criteria) elapsed time 0.448 0.61
repeated bind elapsed time 0.026 0.04
failed parse elapsed time 0.009 0.01
hard parse (bind mismatch) elapsed time 0.002 0
RMAN cpu time (backup/restore) 0 0
inbound PL/SQL rpc elapsed time 0 0
sequence load elapsed time 0 0
Java execution elapsed time 0 0
failed parse (out of shared memory) elapsed time 0 0
可以在V$SYS_TIME_MODEL视图中找到相应的主要花费时间处理的部分,然后就可以根据这些来对数据库进行相应的调整。
除了活动时间,DBA也还想知道整体的等待时间。在Oracle10g数据库之前,
DBA必须查看单独的等待事件来找出等待和瓶颈,现在Oracle10g数据库提供一个等待的概要机制。
select WAIT_CLASS,
TOTAL_WAITS,
round(100 * (TOTAL_WAITS/SUM_WAITS),2) PCT_WAITS,
ROUND((TIME_WAITED/100),2) TIME_WAITED_SECS,
round(100 * (TIME_WAITED/SUM_TIME),2) PCT_TIME
from
(select WAIT_CLASS,
TOTAL_WAITS,
TIME_WAITED
from V$SYSTEM_WAIT_CLASS
where WAIT_CLASS ！= 'Idle'),
(select sum(TOTAL_WAITS) SUM_WAITS,
sum(TIME_WAITED) SUM_TIME
from V$SYSTEM_WAIT_CLASS
where WAIT_CLASS ！= 'Idle')
order by 5 desc;
WAIT_CLASS TOTAL_WAITS PCT_WAITS TIME_WAITED_SECS PCT_TIME
---------------------- ----------- ---------- ---------------- ----------
User I/O 5748 61.71 67.57 65.79
Other 182 1.95 16.85 16.41
System I/O 2975 31.94 11.27 10.97
Concurrency 114 1.22 6.76 6.58
Commit 61 0.65 0.22 0.21
Network 233 2.5 0.03 0.03
Application 2 0.02 0 0
这样就能非常容易的找出大部分的整体等待时间。如同响应时间数据一样,
我们可以用下面的查询来及时回顾最新的一个小时等待类型：
select a.sid,
b.username,
a.wait_class,
a.total_waits,
round((a.time_waited/100),2) time_waited_secs
from sys.v_$session_wait_class a,
sys.v_$session b
where b.sid = a.sid and
b.username is not null and
a.wait_class ！= 'Idle'
order by 5 desc;
SID USERNAME WAIT_CLASS TOTAL_WAITS TIME_WAITED_SECS
----- -------------- -------------- ----------- ----------------
38 SYS User I/O 22 0.19
48 SYS User I/O 15 0.12
38 SYS Network 21 0.01
48 SYS Network 24 0
38 SYS Application 2 0
这个时候,就可以检查标准的单独等待事件就如在以前版本的Oracle数据库中查询V$SESSION_WAIT和V$SESSION_EVENT视图。
在Oracle10g数据库中DBA还将可以找出新的等待类型在这两张视图中。
如果需要找出以前哪个会话登录并且消耗了大部分的资源,
你可以使用下面的查询,下面的例子是查找午夜12点到5点的数据库活动,并且包括用户的I/O等待。
select sess_id,
username,
program,
wait_event,
sess_time,
round(100 * (sess_time/total_time),2) pct_time_waited
from
(select a.session_id sess_id,
decode(session_type,'background',session_type,c.username) username,
a.program program,
b.name wait_event,
sum(a.time_waited) sess_time
from sys.v_$active_session_history a,
sys.v_$event_name b,
sys.dba_users c
where a.event# = b.event# and
a.user_id = c.user_id and
sample_time > '22-JAN-07 12：00：00 AM' and
sample_time < '22-JAN-07 05：00：00 AM' and
b.wait_class = 'User I/O'
group by a.session_id,
decode(session_type,'background',session_type,c.username),
a.program,
b.name);
SQL语句响应时间分析：
在Oracle9i数据库中查看SQL语句的响应时间就变得比较容易了,现在在Oracle10g中,
DBA们拥有更多的工具可以帮助他们跟踪效率低下的数据库代码。
以前可以用来查询的视图是V$SQLAREA,从Oracle9i开始,
这个视图增加了ELAPSED_TIME和CPU_TIME两个列,
这极大的有助于去确定实际用户的SQL语句的执行经历。
(如果除以执行的次数列EXECUTIONS,那么将得到平均每次执行这个SQL语句所用的平均时间)
在Oracle10g数据库中,V$SQLAREA视图中增加了6个新的和等待以及时间相关的列：
l APPLICATION_WAIT_TIME
l CONCURRENCY_WAIT_TIME
l CLUSTER_WAIT_TIME
l USER_IO_WAIT_TIME
l PLSQL_EXEC_TIME
l JAVA_EXEC_TIME
这些新的列有助于确定很多信息,例如：一个存储过程中花费在PL/SQL代码和标准SQL执行上的时间的对比,
以及一个SQL语句经历的任何详细的用户I/O等待。例如：下面的SQL语句能帮助找到前5位用户I/O等待最高的SQL语句：
select * from
(select sql_text,
sql_id,
elapsed_time,
cpu_time,
user_io_wait_time
from sys.v_$sqlarea
order by 5 desc)
where rownum < 6;
SQL_TEXT SQL_ID ELAPSED_TIME CPU_TIME USER_IO_WAIT_TIME
-------------------------------------------------------------------------------- ------------- ------------ ---------- -----------------
DECLARE job BINARY_INTEGER ：= ：job; next_date DATE ：= ：mydate; broken BOOLEAN ： 6gvch1xu9ca3g 11077912 747091 8593479
select /*+ index(idl_ub1$ i_idl_ub11) +*/ piece#,length,piece from idl_ub1$ wher cvn54b7yz0s8u 6455976 220128 6427409
select s.synonym_name object_name, o.object_type from sys.all_synonyms s, s fqmpmkfr6pqyk 11814078 6958760 3189450
select /*+ rule */ bucket, endpoint, col#, epvalue from histgrm$ where obj#=：1 a db78fxqxwxt7r 2737680 193937 2689611
select /*+ index(idl_ub2$ i_idl_ub21) +*/ piece#,length,piece from idl_ub2$ wher 39m4sx9k63ba2 2322664 108100 2307700
当然,获取最消耗时间或者等待时间最长的SQL语句非常不错,
但是同时也需要抓住其要点——在V$ACTIVE_SESSION_HISTORY视图中又一次出现的SQL语句。
通过这个视图,能够找出具体什么等待时间延迟了SQL语句执行,连同实际的文件,对象以及阻塞的对象导致等待。
例如：设想已经找到一个特别的SQL语句,看上去在用户I/O等待时间方面极端的严重,
那么可以执行下面的查询来得到等待时间中各个单独的等待事件,等待的文件,等待的对象：
select event,
time_waited,
owner,
object_name,
current_file#,
current_block#
from sys.v_$active_session_history a,
sys.dba_objects b
where sql_id = '6gvch1xu9ca3g' and
a.current_obj# = b.object_id and
time_waited <> 0;
EVENT TIME_WAITED OWNER OBJECT_NAME file block
------------------------- ----------- ------ --------------------- ---- ------
db file sequential read 27665 SYSMAN MGMT_METRICS_1HOUR_PK 3 29438
db file sequential read 3985 SYSMAN SEVERITY_PRIMARY_KEY 3 52877
当然,也可以通过使用V$ACTIVE_SESSION_HISTORY视图中的历史数据的方式来限制一段特殊时间内的没有优化的SQL语句。问题在于Oracle10g数据库通过简化的数据字典视图把SQL语句的响应时间分析变得非常的简单,比起以前运用消耗时间的trace方法来说。
总结：
DBA们和性能分析专家们管理Oracle10g数据库的性能时会发现在最新的Oracle旗舰数据库中已经把许多的响应时间数据做成了动态性能视图。这些统计信息将有助于迅速找出大型复杂数据库中的性能瓶颈所在。
在Oracle10g中,以前版本中比较难于获取的响应时间数据将会变得非常容易获取。
在以前看来,为了尽量获得数据库的最佳性能,Oracle的DBA们和性能分析专家一直很困难获得系统以及用户会话活动的一致的响应时间数据。DBA们面临的问题一直以来包括两个方面：第一个方面是准确定位数据库或者用户会话究竟在哪里消耗了时间;第二个方面就是确定用户体验的客观性质。
在数据库中产生所有可能的行为和交互作用,这些任务都不是没有价值的。
Oracle等待接口,在之前的很早的Oracle数据库版本中开始介绍的,
对于那些知道如何使用等待接口的管理员来说这已经成为一个伟大的开始,
即使它仍然缺乏告诉DBA系统或者用户会话是否有效的处理了事务或者查询这个理想的能力。
启用和钻研跟踪文件能够存储这个级别上的详细信息,但是对于大多数超负荷工作管理大型数据库的DBA们,
这个钻研是奢侈的而耗费时间的。
幸运的是,那些将数据库升级到Oracle10g的DBA们将会发现找到主要的响应时间变得很容易,
可以允许一个非常好的图表来显示系统和会话级的响应时间数据。
很重要的一点,Oracle的ADDM提供了一个查看响应时间的方法,通过自动分析收集的统计信息,识别问题区域,
甚至可以通过Oracle企业管理器网络控制的图形界面提供建议。
此外,与我们这里讨论相关的是Oracle10g数据库的历史数据机制允许DBA们按时查看对响应时间趋势的分析,
这将有助于DBA们确定事务/系统的高峰时期,更好的定位那些拉长批处理周期和ETL作业的进程和SQL语句。
这里主要讨论用于系统、会话和SQL级别上那些历史机制的用途。
系统层的响应时间分析：
先来看看典型的几个经常问到DBA们的问题：
通常来说,数据库运行的状况如何？
用户体验感觉的平均响应时间是多少？
什么行为是最影响整个响应时间的？
上述问题在Oracle10g数据库之前对于DBA们来说是相当不好回答的,
但是如果使用了最新的Oracle10g数据库之后,这些数据信息将会很容易的被捕获到。
首先,Oracle10g数据库运行的状况如何这个问题可以通过下面的查询来获得：
select METRIC_NAME,VALUE
from SYS.V_$SYSMETRIC
where METRIC_NAME IN ('Database CPU Time Ratio','Database Wait Time Ratio')
AND INTSIZE_CSEC = (select max(INTSIZE_CSEC) from SYS.V_$SYSMETRIC);
METRIC_NAME VALUE
------------------------------ ----------------------------------
Database Wait Time Ratio 31.3499111
Database CPU Time Ratio 68.6500888
Oracle10g数据库中的V$SYSMETRIC视图中存在一些非常有用的响应时间数据,
其中两个比较重要的就是Wait Time Ratio 和Database CPU Time Ratio.
上面的查询显示了数据库中最新的关于这两个统计数据的快照,
这将有助于帮助我们确定是否数据库正在经历着一个比较高的等待百分率和瓶颈。
数据库的CPU Time Ratio是由数据库中的"database time"的数值除以CPU的数量,
"database time"定义为数据库消耗在用户级别调用所花费的时间(不包括实例的后台进程活动所消耗的时间)。
比较高的值(90%-95%以上)代表很少的 等待和瓶颈活动,因为各个系统不同,这个阀值只能作为一个一般的规则来使用。
还可以使用如下的查询来迅速查看最新一个小时的信息,看看数据库的总性能如何：
select end_time,value
from sys.v_$sysmetric_history
where metric_name = 'Database CPU Time Ratio'
order by 1;
END_TIME VALUE
----------- --------------
2007-1-24 2 3.21949216
2007-1-24 2 3.01443414
2007-1-24 2 9.75636353
2007-1-24 2 9.28581409
2007-1-24 2 43.3490481
2007-1-24 2 38.8366361
2007-1-24 2 32.0272511
2007-1-24 2 0
2007-1-24 2 22.9580733
2007-1-24 2 33.0615102
2007-1-24 2 43.1294933
可以从V$SYSMETRIC_SUMMARY视图中获得数据库整体性能效率的最大、最小和平均值：
select CASE METRIC_NAME
WHEN 'SQL Service Response Time' then 'SQL Service Response Time (secs)'
WHEN 'Response Time Per Txn' then 'Response Time Per Txn (secs)'
ELSE METRIC_NAME
END METRIC_NAME,
CASE METRIC_NAME
WHEN 'SQL Service Response Time' then ROUND((MINVAL/100),2)
WHEN 'Response Time Per Txn' then ROUND((MINVAL/100),2)
ELSE MINVAL
END MININUM,
CASE METRIC_NAME
WHEN 'SQL Service Response Time' then ROUND((MAXVAL/100),2)
WHEN 'Response Time Per Txn' then ROUND((MAXVAL/100),2)
ELSE MAXVAL
END MAXIMUM,
CASE METRIC_NAME
WHEN 'SQL Service Response Time' then ROUND((AVERAGE/100),2)
WHEN 'Response Time Per Txn' then ROUND((AVERAGE/100),2)
ELSE AVERAGE
END AVERAGE
from SYS.V_$SYSMETRIC_SUMMARY
where METRIC_NAME in ('CPU Usage Per Sec',
'CPU Usage Per Txn',
'Database CPU Time Ratio',
'Database Wait Time Ratio',
'Executions Per Sec',
'Executions Per Txn',
'Response Time Per Txn',
'SQL Service Response Time',
'User Transaction Per Sec')
ORDER BY 1;
METRIC_NAME MININUM MAXIMUM AVERAGE
---------------------------------------------- ---------- ----------
CPU Usage Per Sec 0 53.9947577 11.1603280
CPU Usage Per Txn 0 168.731666 24.8848615
Database CPU Time Ratio 0 87.1866295 35.8114730
Database Wait Time Ratio 0 90.7141859 64.1885269
Executions Per Sec 0 540.768348 114.852472
Executions Per Txn 0 1911 279.912779
Response Time Per Txn (secs) 0 3.88 0.66
SQL Service Response Time (secs) 0 0 0
User Transaction Per Sec 0 4.70183486 0.94469007
上面的查询包含了更多的详细的响应时间数据。DBA们还需要收集在系统级别上的用户通讯的平均响应时间,
上面的查询给出了需要的结果。
如果用户抱怨响应时间太慢,那么DBA就应该查看Response Time Per Txn
和SQL Service Response Time数据是否存在数据库问题。
如果响应时间不在是那么渴求,那么DBA就会想了解究竟是什么类型的用户活动让数据库的响应变得如此的慢,
在Oracle10g数据库之前,这些信息 是比较难获取的,但是现在就变得非常容易,执行如下查询：
select case db_stat_name
when 'parse time elapsed' then
'soft parse time'
else db_stat_name
end db_stat_name,
case db_stat_name
when 'sql execute elapsed time' then
time_secs - plsql_time
when 'parse time elapsed' then
time_secs - hard_parse_time
else time_secs
end time_secs,
case db_stat_name
when 'sql execute elapsed time' then
round(100 * (time_secs - plsql_time)/db_time,2)
when 'parse time elapsed' then
round(100 * (time_secs - hard_parse_time)/db_time,2)
else round(100 * time_secs/db_time,2)
end pct_time
from
(select stat_name db_stat_name,
round((value/1000000),3) time_secs
from sys.v_$sys_time_model
where stat_name not in('DB time','background elapsed time',
'background cpu time','DB CPU')),
(select round((value/1000000),3) db_time
from sys.v_$sys_time_model
where stat_name = 'DB time'),
(select round((value/1000000),3) plsql_time
from sys.v_$sys_time_model
where stat_name = 'PL/SQL execution elapsed time'),
(select round((value/1000000),3) hard_parse_time
from sys.v_$sys_time_model
where stat_name = 'hard parse elapsed time')
order by 2 desc;
DB_STAT_NAME TIME_SECS PCT_TIME
---------------------------------------------------------------- ---------- ----------
sql execute elapsed time 65.644 89.7
hard parse elapsed time 26.661 36.43
PL/SQL execution elapsed time 12.766 17.44
PL/SQL compilation elapsed time 6.353 8.68
soft parse time 2.15 2.94
connection management call elapsed time 1.084 1.48
hard parse (sharing criteria) elapsed time 0.448 0.61
repeated bind elapsed time 0.026 0.04
failed parse elapsed time 0.009 0.01
hard parse (bind mismatch) elapsed time 0.002 0
RMAN cpu time (backup/restore) 0 0
inbound PL/SQL rpc elapsed time 0 0
sequence load elapsed time 0 0
Java execution elapsed time 0 0
failed parse (out of shared memory) elapsed time 0 0
可以在V$SYS_TIME_MODEL视图中找到相应的主要花费时间处理的部分,然后就可以根据这些来对数据库进行相应的调整。
除了活动时间,DBA也还想知道整体的等待时间。在Oracle10g数据库之前,
DBA必须查看单独的等待事件来找出等待和瓶颈,现在Oracle10g数据库提供一个等待的概要机制。
select WAIT_CLASS,
TOTAL_WAITS,
round(100 * (TOTAL_WAITS/SUM_WAITS),2) PCT_WAITS,
ROUND((TIME_WAITED/100),2) TIME_WAITED_SECS,
round(100 * (TIME_WAITED/SUM_TIME),2) PCT_TIME
from
(select WAIT_CLASS,
TOTAL_WAITS,
TIME_WAITED
from V$SYSTEM_WAIT_CLASS
where WAIT_CLASS ！= 'Idle'),
(select sum(TOTAL_WAITS) SUM_WAITS,
sum(TIME_WAITED) SUM_TIME
from V$SYSTEM_WAIT_CLASS
where WAIT_CLASS ！= 'Idle')
order by 5 desc;
WAIT_CLASS TOTAL_WAITS PCT_WAITS TIME_WAITED_SECS PCT_TIME
---------------------- ----------- ---------- ---------------- ----------
User I/O 5748 61.71 67.57 65.79
Other 182 1.95 16.85 16.41
System I/O 2975 31.94 11.27 10.97
Concurrency 114 1.22 6.76 6.58
Commit 61 0.65 0.22 0.21
Network 233 2.5 0.03 0.03
Application 2 0.02 0 0
这样就能非常容易的找出大部分的整体等待时间。如同响应时间数据一样,
我们可以用下面的查询来及时回顾最新的一个小时等待类型：
select a.sid,
b.username,
a.wait_class,
a.total_waits,
round((a.time_waited/100),2) time_waited_secs
from sys.v_$session_wait_class a,
sys.v_$session b
where b.sid = a.sid and
b.username is not null and
a.wait_class ！= 'Idle'
order by 5 desc;
SID USERNAME WAIT_CLASS TOTAL_WAITS TIME_WAITED_SECS
----- -------------- -------------- ----------- ----------------
38 SYS User I/O 22 0.19
48 SYS User I/O 15 0.12
38 SYS Network 21 0.01
48 SYS Network 24 0
38 SYS Application 2 0
这个时候,就可以检查标准的单独等待事件就如在以前版本的Oracle数据库中查询V$SESSION_WAIT和V$SESSION_EVENT视图。
在Oracle10g数据库中DBA还将可以找出新的等待类型在这两张视图中。
如果需要找出以前哪个会话登录并且消耗了大部分的资源,
你可以使用下面的查询,下面的例子是查找午夜12点到5点的数据库活动,并且包括用户的I/O等待。
select sess_id,
username,
program,
wait_event,
sess_time,
round(100 * (sess_time/total_time),2) pct_time_waited
from
(select a.session_id sess_id,
decode(session_type,'background',session_type,c.username) username,
a.program program,
b.name wait_event,
sum(a.time_waited) sess_time
from sys.v_$active_session_history a,
sys.v_$event_name b,
sys.dba_users c
where a.event# = b.event# and
a.user_id = c.user_id and
sample_time > '22-JAN-07 12：00：00 AM' and
sample_time < '22-JAN-07 05：00：00 AM' and
b.wait_class = 'User I/O'
group by a.session_id,
decode(session_type,'background',session_type,c.username),
a.program,
b.name);
SQL语句响应时间分析：
在Oracle9i数据库中查看SQL语句的响应时间就变得比较容易了,现在在Oracle10g中,
DBA们拥有更多的工具可以帮助他们跟踪效率低下的数据库代码。
以前可以用来查询的视图是V$SQLAREA,从Oracle9i开始,
这个视图增加了ELAPSED_TIME和CPU_TIME两个列,
这极大的有助于去确定实际用户的SQL语句的执行经历。
(如果除以执行的次数列EXECUTIONS,那么将得到平均每次执行这个SQL语句所用的平均时间)
在Oracle10g数据库中,V$SQLAREA视图中增加了6个新的和等待以及时间相关的列：
l APPLICATION_WAIT_TIME
l CONCURRENCY_WAIT_TIME
l CLUSTER_WAIT_TIME
l USER_IO_WAIT_TIME
l PLSQL_EXEC_TIME
l JAVA_EXEC_TIME
这些新的列有助于确定很多信息,例如：一个存储过程中花费在PL/SQL代码和标准SQL执行上的时间的对比,
以及一个SQL语句经历的任何详细的用户I/O等待。例如：下面的SQL语句能帮助找到前5位用户I/O等待最高的SQL语句：
select * from
(select sql_text,
sql_id,
elapsed_time,
cpu_time,
user_io_wait_time
from sys.v_$sqlarea
order by 5 desc)
where rownum < 6;
SQL_TEXT SQL_ID ELAPSED_TIME CPU_TIME USER_IO_WAIT_TIME
-------------------------------------------------------------------------------- ------------- ------------ ---------- -----------------
DECLARE job BINARY_INTEGER ：= ：job; next_date DATE ：= ：mydate; broken BOOLEAN ： 6gvch1xu9ca3g 11077912 747091 8593479
select /*+ index(idl_ub1$ i_idl_ub11) +*/ piece#,length,piece from idl_ub1$ wher cvn54b7yz0s8u 6455976 220128 6427409
select s.synonym_name object_name, o.object_type from sys.all_synonyms s, s fqmpmkfr6pqyk 11814078 6958760 3189450
select /*+ rule */ bucket, endpoint, col#, epvalue from histgrm$ where obj#=：1 a db78fxqxwxt7r 2737680 193937 2689611
select /*+ index(idl_ub2$ i_idl_ub21) +*/ piece#,length,piece from idl_ub2$ wher 39m4sx9k63ba2 2322664 108100 2307700
当然,获取最消耗时间或者等待时间最长的SQL语句非常不错,
但是同时也需要抓住其要点——在V$ACTIVE_SESSION_HISTORY视图中又一次出现的SQL语句。
通过这个视图,能够找出具体什么等待时间延迟了SQL语句执行,连同实际的文件,对象以及阻塞的对象导致等待。
例如：设想已经找到一个特别的SQL语句,看上去在用户I/O等待时间方面极端的严重,
那么可以执行下面的查询来得到等待时间中各个单独的等待事件,等待的文件,等待的对象：
select event,
time_waited,
owner,
object_name,
current_file#,
current_block#
from sys.v_$active_session_history a,
sys.dba_objects b
where sql_id = '6gvch1xu9ca3g' and
a.current_obj# = b.object_id and
time_waited <> 0;
EVENT TIME_WAITED OWNER OBJECT_NAME file block
------------------------- ----------- ------ --------------------- ---- ------
db file sequential read 27665 SYSMAN MGMT_METRICS_1HOUR_PK 3 29438
db file sequential read 3985 SYSMAN SEVERITY_PRIMARY_KEY 3 52877
当然,也可以通过使用V$ACTIVE_SESSION_HISTORY视图中的历史数据的方式来限制一段特殊时间内的没有优化的SQL语句。问题在于Oracle10g数据库通过简化的数据字典视图把SQL语句的响应时间分析变得非常的简单,比起以前运用消耗时间的trace方法来说。
总结：
DBA们和性能分析专家们管理Oracle10g数据库的性能时会发现在最新的Oracle旗舰数据库中已经把许多的响应时间数据做成了动态性能视图。这些统计信息将有助于迅速找出大型复杂数据库中的性能瓶颈所在。
分享到：
发表评论
相关推荐
本文从数据库系统级和SQL语句级两个方面进行了深入的分析，旨在帮助数据库管理员和性能分析人员获得真实可靠的系统响应时间和会话活动的响应时间。 一、数据库系统级响应时间的分析 在网络数据库中，为了提高性能...
### Oracle性能分析工具详解 #### 一、性能规划器(Capacity Planner)概述 性能规划器（Capacity Planner）是一款强大的工具，集成于Oracle企业治理包（Oracle Enterprise Management Packs）之中，主要用于收集和...
Oracle性能分析是数据库管理员在日常工作中至关重要的一环，它涉及到CPU使用率、内存管理、I/O性能等多个关键领域。本文将深入探讨这些方面，并提供一些基础的分析工具和方法。 首先，数据库配置报告是进行性能分析...
OWI通过等待事件来收集数据库的运行情况，等待事件是Oracle性能分析的基础，如SQL等待、I/O等待、锁等待等。 2. **性能调整基础**：性能优化的目标是最大化数据库的吞吐量，减少响应时间，并确保系统的稳定性和可...
本主题聚焦于"Oracle.10g性能分析与优化思路"，旨在深入探讨如何通过一系列技术手段和策略让Oracle数据库运行得更加流畅、快速。 一、SQL优化 1. SQL执行计划分析：了解SQL语句的执行过程，利用 Explain Plan 工具...
对于Oracle数据库无响应故障的处理，首先需要准确判断故障的具体表现形式和影响范围，然后结合故障现象进行深入分析，找出可能导致故障的根本原因。针对不同的故障原因，采取相应的措施进行修复。例如，如果是由于...
根据提供的信息，我们可以推断出这本名为“高级owi与oracle性能调整”的书籍主要讨论了高级owi技术以及Oracle数据库性能优化的相关内容。由于提供的部分页面信息仅包含联系方式，并没有具体的章节内容，因此以下将...
Oracle性能分析工具是数据库管理员用来监控和优化Oracle数据库性能的关键工具。本文主要介绍了Oracle性能规划器的使用方法，这是Oracle企业治理包的一部分，用于收集、存储和分析系统性能参数。 性能规划器的主要...
除了上述两点，Oracle性能优化还包括索引的建立与管理，分区策略的运用，回滚段的优化，以及查询执行计划的控制等。索引能加速数据检索，但过度的索引会增加写操作的开销，需权衡利弊。分区策略可将大表分解，提高...
2. **数据库活动**：跟踪会话数、并发用户、等待事件等，这可以帮助我们了解系统负载和响应时间。`v$session`和`v$waitstat`视图可以提供这些信息。 3. **SQL性能**：分析最耗时的SQL语句，找出可能影响性能的查询...
Oracle性能测试是数据库管理员和IT专业人员至关重要的任务，它涉及到评估Oracle数据库系统的运行效率，以确保数据处理速度、响应时间和资源利用率等关键指标达到预期标准。以下是对Oracle性能测试的详细解读： 一、...
### Oracle性能优化求生指南 #### 一、Oracle数据库性能优化概述 在现代企业环境中，Oracle数据库因其稳定性和强大的功能而被广泛采用。然而，随着数据量的不断增长和技术的快速发展，确保Oracle数据库的高性能变...
在执行`UPDATE`操作时，性能分析至关重要，因为它直接影响到系统的响应时间和资源消耗。Oracle提供了多种工具和方法来帮助进行性能调优，包括但不限于： - **执行计划分析**：使用`EXPLAIN PLAN`命令可以查看`UPDATE...
【虚拟化环境中Oracle数据库的性能分析】 随着虚拟化技术的广泛应用，越来越多的企业和机构选择将数据库系统部署在虚拟环境中，以提高资源利用率和管理效率。然而，虚拟化环境对数据库性能的影响是关注的焦点，尤其...
### ORACLE 健康检查与性能分析报告 #### 1. 报告综述 ##### 1.1 目的说明 本报告的主要目的是针对指定时间段内的Oracle数据库进行全面的健康检查及性能分析，旨在识别潜在的问题并提供相应的改进建议。通过本次...
Oracle性能优化工具整理 Oracle数据库作为全球广泛使用的商业数据库管理系统，其性能优化对于确保数据库稳定运行、提高应用响应速度至关重要。性能优化不仅需要通过合理设计数据库模式、编写高效SQL语句等手段，而且...
Oracle RAC（Real Application Clusters）数据库性能分析是数据库管理员关注的重要领域，它涉及到系统稳定性、响应速度以及资源利用率等多个方面。以下是对标题和描述中提及的几个关键知识点的详细阐述： 1. **...