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;