oracle 大事务的并行恢复导致数据库性能下降--cpu使用率较高处理思路

  oracle 大事务的并行恢复导致数据库性能下降--cpu使用率较高处理思路 

  大型事务的回滚 大型事务的回滚产生非常大的代价，不仅锁定需要的资源

，并且消耗的CPU和IO，尤其是IO将极为密集。这个时候，希望降低回滚所产生

的影响。停止是不可能的，为了保持数据库的一致性，回滚必须完成，所以只

能降低影响。参数fast_start_parallel_rollback可以实现这个调剂，缺省值

为low，表示启动2倍CPU数量的并行进程进行回滚。另外还有high和false两个

值，high表示以4倍CPU数量的并行进程进行回滚。该参数可以动态设置，但是

动态设置可能无法中断并行恢复，重新设置启动为最好的方法，设置

fast_start_parallel_rollback=false之后重新启动数据库即可。
 在数据库重新启动之后，v$TRANSACTION视图中将不存在事务信息，
 但是V$fast_start_transactions视图可以查找回滚完成了多少。

 在大型数据库中，一个大型操作的失败代价是比较高的，严重时甚至会引起数

据库挂起。尤其在KILL大型事务之前检查事务究竟有多大可能是必要的，同时

我们也需要知道回滚已经进行了多少程度。 V$transaction，v$session关联得

到事务大小。 Select t.used_ublk from v$transaction t v$session s

Where t.ses_addr=s.saddr and s.sid=&sid
在事务失败或者kill session之后，持续的监控该语句结果来估计回滚进度。

如果观察到used_ublk几乎不动或者回滚非常慢，可以确定以下是否由于并行恢

复引起（并行恢复有时会引起数据库恢复挂起）。在并行恢复情况下，Smon将

会抓住TX lock，同时应该存在某些PS lock PX进程占用大量的CPU资源。V

$fast_start_servers和v$fast_start_transaction两张视图表示是否执行了并

行恢复。如果发现并行恢复很慢，可以尝试把并行恢复关掉看看是否可以加快

rollback。alter system set fast_start_parallel_rollback = false 该语

句关掉并行rollback 改用串行化。 同样如果是串行化ROLLBACK，同时CPU资源

尚可的话，可以采用并行恢复的方式来加快回滚。如果整体系统已经基本显示

挂住，可以shutdown数据库起用并行rollback。并行恢复可以在$session_wait

中看到很多PX进程等待，Smon进程作为协调进程同时在等待PX进程完成。 数据

库关闭或者kill shadow process之后，在v$transaction中将不能发现事务信

息。这时候在v$fast_start_transaction中有事务信息。如果是8i以前版本，

只能持续监控uet$和fet$表格来查看是否进行rollback，同时Smon应该经常抓

住ST lock。

碰到数据库性能下降，首先要做的事情：
1.首先查找os方面的信息：
top  ---查看那个进程占据系统资源最多---这里一般也可以看出是那个进程占

用资源最多。
mem---的使用情况，是否存在大量换页。
系统---i/o是否正常。

2.AWR ---》top 5 user event

这里针对大事务的并行恢复案例做一个简单的分析

1.在awr报告中看到wait for a undo record

----查看历史信息
2.select event,count(*)  from dba_hist_active_sess_history
  where sample_time < to_timestamp

('20130923093000','yyyymmddhh24mis')
and sample_time > to_timestamp('20130923093000','yyyymmddhh24mis')
and  instance_number=1
group by event
order by 2;

---查看那些进程出现了 wait for a undo record
SQL> select sample_time time, session_id sid,

event,p1,p2,program,sql_id
  2  from dba_hist_active_sess_history
  3  where event = 'wait for a undo record'  
  4  order by sample_time;

问题解决：
找到smon 进程：
SQL> select pid,program from v$process where program like '%SMON%';

       PID PROGRAM
---------- ------------------------------------------------
         8 oracle@localhost.localdomain (SMON)

关闭smon的事务恢复功能：
oradebug setorapid 8

oradebug event 10513 trace name context forever ,level 2;

关闭并行事务回滚：
alter system set fast_start_parallel_rollback=false;

重新打开smon事务恢复功能：
oradebug setorapid 8

oradebug event 10513 trace name context off;

确定事务恢复情况：
select * from V$fast_start_transactions;