【翻譯自mos文章】當並行事務恢複進程在運行時，禁用並行事務恢複的方法，mos事務

【翻譯自mos文章】當並行事務恢複進程在運行時，禁用並行事務恢複的方法，mos事務

當並行事務恢複進程在運行時，禁用並行事務恢複的方法
How to Disable Parallel Transaction Recovery When Parallel Txn Recovery is Active (Doc ID 238507.1)

適用於：
Oracle Database - Enterprise Edition - Version 8.1.5.0 to 11.2.0.4 [Release 8.1.5 to 11.2]
Oracle Database - Personal Edition - Version 8.1.5.0 to 11.2.0.4 [Release 8.1.5 to 11.2]
Information in this document applies to any platform.

癥狀：
Parallel Transaction Recovery  花費了很長時間
你可以使用V$TRANSACTION視圖的USED_UBLK列來估計rollback需要多長時間，但並沒有公式來計算該時間。
如果你在rollback 已經啟動之後，再shutdown database，rollback會在停止的地方再啟動。

你可以看一下V$FAST_START_TRANSACTIONS視圖中的兩列的對比： UNDOBLOCKSDONE  和 UNDOBLOCKSTOTAL

變動：
一個大事務 被kill掉 或者被rolled back

原因：
並行事務恢複（ parallel transaction recovery ） 不如串列復原快的例子很多，原因是pq slaves進程會相互幹擾（interfer）
這取決於需要rollback的類型，一般發生在roll back 並行 index update上。

解決方案：
線上地把並行恢複改為串列。若是cluster環境，需要在所有的執行個體上同時修改

1. 找到smon的 oracle pid （注意不是os pid）
SQL> select pid, program from v$process where program like '%SMON%';

       PID PROGRAM
---------- ------------------------------------------------
         6 oracle@stsun7 (SMON)
        

2. disable smon transaction cleanup
SQL> oradebug setorapid 'SMON's Oracle PID';
SQL> oradebug event 10513 trace name context forever, level 2

3.從os層面kill掉那些正在執行並行事務恢複的pq slave進程。可以通過V$FAST_START_SERVERS 來找到這些pq slave進程

select SPID from V$PROCESS where PID in (select PID from V$FAST_START_SERVERS);

然後從os層面kill 掉上面select語句的查詢結果： kill -9 spid

4. 關閉fast_start_parallel_rollback
alter system set fast_start_parallel_rollback=false;

5.重新啟動 事務恢複（transaction recovery ）
SQL> oradebug setorapid 'SMON's Oracle PID';
SQL> oradebug event 10513 trace name context off

aspnet 運行錯誤：OleDbConnection 不支援並行事務

你在事務中用了兩個connection,就會這樣,
解決方案:用一個了,