Top 5 Timed Events
~~~~~~~~~~~~~~~~~~ % Total
Event Waits Time (s) Ela Time
-------------------------------------------- ------------ ----------- ------
buffer busy global CR 1,105,605 181,354 26.51
global cache cr request 13,655,069 160,309 23.44
latch free 3,812,488 110,950 16.22
buffer busy waits 5,073,632 84,394 12.34
db file scattered read 8,261,925 78,891 11.53
如果判断该语句的大量并发将导致系统故障，需要按以下方法进行处理。
该问题的根本原因是由于一次硬解析时选择了一个极端的非最优执行计划。一般情况下，此时再出发一次硬解析时又会重新选择正确的执行计划。可以通过如下方法在该问题再次出现时，紧急处理。
execute dbms_stat.set_table_stats(ownname=><user_name>, tabname=><table_name>, no_invalidation=>true);
替换其中的user_name和table_name为相应的用户名及表名，如：
execute dbms_stats.set_table_stats(ownname=>'HR',tabname=>'REGIONS', no_invalidate=>true);
grant select on <table_name> to public;
revoke select on <table_name> from public;
该步骤，如果第一句执行后已经产生了正确的执行计划，则该后面的revoke可以选择在非业务繁忙时段再做
将表分析的信息导回数据库，找出异常的
hash_value:
select
'EXEC DBMS_STATS.IMPORT_TABLE_STATS(OWNNAME=>'
||object_owner||
'TABNAME=>'
||object_name||
'STATOWN=>'
'PERFSTAT'
'STATTAB=>'
'CTZJ_STAT'
'CASCADE=>TRUE'
'STATID=>1'
'no_invalidate=>true'
(select
distinct
object_name
object_owner
v$sql_plan
where
operation
'TABLE ACCESS'
object_owner
'SIEBEL'
optimizer
'ANALYZED'
hash_value
'hash_value'
建议将相关的统计信息全部导入。
对相关表进行统计信息分析;
Exec dbms_stats.gather_table_stats(ownname=>’siebel’, tabname=>’S_ORDER’, estimate_percent=>
0.0001
, cascade=>true);
Estimate_percent
可以根据情况进行调整。
alter system flush shared_pool;
重启实例（慎重）
建议采取方法1或方法2，可以以较小的代价触发新的硬解析，以期产生最优的执行计划。同时，在利用以上方式使得原有的CURSOR失效之后， DBA可以使用拥有较好赋值的该语句手工执行一次，从而保证新的硬解析之后会产生最优的执行计划，避免可能的新的硬解析之后又会产生非最优的执行计划的情形。如果能够保证使用较好的赋值的绑定变量的语句执行了第一次硬解析，则能够保证由于该问题导致的系统性能下降会在该语句被正常执行后的很短时间内恢复正常。
方法5或方法6一般不建议采用。
在分析trace信息后，如果确定确实由于bind peeking特定引起的执行计划发生改变导致了性能下降，则可以考虑关闭该特性。
但是关闭该特性会引起数据库无法根据实际的情况动态选择最优执行计划，请考虑对整体业务的影响。
关闭该特性的命令如下：
alter system set "_optim_peek_user_binds"=false scope=spfile
重启数据库
在init.ora参数文件中设置
"_optim_peek_user_binds"=false
重起数据库使参数生效
在未分析trace信息之前，不建议进行该参数设置。
发现执行计划异常可从几个方面
:
从等待事件
select event,sql_hash_value,count(*) ,(count(*)*2-sum(inst_id)) RAC_1,(sum(inst_id)-count(*)) RAC_2,max(username) user1,min(username) user2 ,max(machine) machine1,min(machine) machine2 from (
select a.inst_id, event,username,decode(sql_hash_value,0,prev_hash_value,sql_hash_value) sql_hash_value,machine from gv$session_wait a,
gv$session b where a.inst_id=b.inst_id and a.sid=b.sid and a.event not in (select event from perfstat.stats$idle_event))
group by event,sql_hash_value order by count(*) desc;
从语句执行时间
select sid||','||serial# sid,status,username,logon_time,last_call_et,machine,process,sql_hash_value
,prev_hash_value,inst_id iid,'alter system kill session '''||sid||','||serial#||''';' kill_text
from gv$session where status<>'INACTIVE' and type='USER' and last_call_et>1 order by last_call_et desc;
如果看到有一语句上执行时间长
很可能是执行计划异常
特别是只在其中一个实例上有
可以确认是执行计划异常
select sql_hash_value,count(*),round(avg(last_call_et)) avg_time
from gv$session where status<>'INACTIVE' and type='USER' and last_call_et>1 and sql_hash_value<>0 group by sql_hash_value order by count(*) desc;
select snap_time,a.* from perfstat.stats$sql_plan_usage a, perfstat.stats$snapshot b where a.snap_id=b.snap_id
and a.hash_value=:hash_value order by snap_time desc
确认后按处理过程文档方法进行处理
注意相关的处理都会引起
libary cache pin,
如果前台没有上报问题
可等到中午
12:00
按文档处理后
,KILL
掉当前在运行的
session:
select 'alter system kill session '''||sid||','||serial#||''';' kill_text
from gv$session where status<>'INACTIVE' and type='USER' and sql_hash_value=:sql_hash_value and last_call_et>1 order by last_call_et desc
广播电视节目制作经营许可证(京) 字第1234号 中国互联网协会会员
