首页  »   数据库

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

网友分享于:2013-10-22  浏览:11次
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;

相关解决方案

最新解决方案