当前位置:Gxlcms > mysql > 【翻译自mos文章】当并行事务恢复进程在运行时,禁用并行事务恢

【翻译自mos文章】当并行事务恢复进程在运行时,禁用并行事务恢

时间:2021-07-01 10:21:17 帮助过:22人阅读

当并行事务恢复进程在运行时,禁用并行事务恢复的方法 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

当并行事务恢复进程在运行时,禁用并行事务恢复的方法
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

人气教程排行