parallel rollback参数总结
fast_start_parallel_rollback
该参数是oracle 8i引入的，详细信息如下表所示：Version Parameter Type Modifiable 11.1.0.7 fast_start_parallel_rollback STRING ALTER SYSTEM (IMMEDIATE) 11.1.0.6 fast_start_parallel_rollback STRING ALTER SYSTEM (IMMEDIATE) 10.2.0.4 fast_start_parallel_rollback STRING ALTER SYSTEM (IMMEDIATE) 10.2.0.3 fast_start_parallel_rollback STRING ALTER SYSTEM (IMMEDIATE) 10.1.0.5 fast_start_parallel_rollback STRING ALTER SYSTEM (IMMEDIATE) 10.1.0.4 fast_start_parallel_rollback STRING ALTER SYSTEM (IMMEDIATE) 9.2.0.8 fast_start_parallel_rollback STRING ALTER SYSTEM (IMMEDIATE) 9.0.1.4 fast_start_parallel_rollback STRING ALTER SYSTEM (IMMEDIATE) 8.1.7.4 fast_start_parallel_rollback STRING ALTER SYSTEM (IMMEDIATE)
该参数如下3种属性值：false --即是关闭parallel rollback功能
low --也是10g的默认值，该值含有是最大的rollback 进程为 2*cpu_count个
high --当设置为该值时，最大的rollback 进程为4*cpu_count个当然其最大值是要受参数parallel_max_servers的影响的，如果是rac环境，那么还跟参数
parallel_threads_per_cpu有关系，这里需要说明一点的是，该参数跟recovery_parallelism不同的，
recovery_parallelism参数是指在进行instance crash recovery时的并行恢复进程个数。关于并行rollback 操作，我们可以通过观察几个试图来进行判断其回滚的时间，如下的几个试图就是
我们需要进行查询的：
v$fast_start_transactions
V$FAST_START_SERVERS
或x$ktuxe下面我们通过例子来进行说明.
SQL> show parameter rollbackNAME TYPE VALUE
------------------------------------ ----------- ------------------------------
_cleanup_rollback_entries integer 100
_corrupted_rollback_segments string
_max_cr_rollbacks integer 0
_offline_rollback_segments string
_rollback_segment_count integer 0
_rollback_segment_initial integer 1
_rollback_stopat integer 0
fast_start_parallel_rollback string LOW --10g中的默认值
rollback_segments string
transactions_per_rollback_segment integer 5
SQL>SQL> show user
USER is "ROGER"
SQL> select count(*) from ht1;COUNT(*)
----------
999SQL> begin
2 for i in 1 .. 1000 loop
3 insert /*+ append */
4 into ht1
5 select * from ht1;
6 commit;
7 end loop;
8 end;
9 /
begin
*
ERROR at line 1:
ORA-01653: unable to extend table ROGER.HT1 by 1024 in tablespace ROGER
ORA-06512: at line 3
SQL> select count(*) from ht1;COUNT(*)
----------
1022976
SQL>
----在当前session执行全表的delete操作，如下：
SQL> delete from ht1;
1022976 rows deleted.
SQL> ---时间大约1分钟左右----在另一窗口进行如下查询：
SQL> show user
USER is "SYS"
SQL> set lines 200
SQL> select XIDUSN,XIDSLOT,XIDSQN,NAME,START_UBASQN,START_UBAREC from v$transaction;
XIDUSN XIDSLOT XIDSQN NAME START_UBASQN START_UBAREC
---------- ---------- ---------- ------------------------- ------------ ------------
6 31 234 221 1
SQL> select KTUXEUSN, KTUXESLT, KTUXESQN, KTUXECFL, KTUXESIZ, sysdate
2 from x$ktuxe
3 where KTUXEUSN = 6
4 and KTUXESLT = 31;
KTUXEUSN KTUXESLT KTUXESQN KTUXECFL KTUXESIZ SYSDATE
---------- ---------- ---------- ------------------------ ---------- ---------
6 31 234 NONE 38912 07-OCT-11SQL>---下面进行rollback time计算
SQL> show user
USER is "ROGER"
SQL> set timing on
SQL>
SQL> rollback;
Rollback complete.
Elapsed: 00:00:46.53
SQL>---该rollback操作花费了46.53秒。---另外窗口
SQL> alter session set nls_date_format='yyyy-mm-dd hh24:mi:ss';
Session altered.Elapsed: 00:00:00.04
SQL> select KTUXEUSN, KTUXESLT, KTUXESQN, KTUXECFL, KTUXESIZ, sysdate
2 from x$ktuxe
3 where KTUXEUSN = 6
4 and KTUXESLT = 31;
KTUXEUSN KTUXESLT KTUXESQN KTUXECFL KTUXESIZ SYSDATE
---------- ---------- ---------- ------------------------ ---------- -------------------
6 31 234 NONE 3616 2011-10-07 06:32:45Elapsed: 00:00:00.00
SQL> /
KTUXEUSN KTUXESLT KTUXESQN KTUXECFL KTUXESIZ SYSDATE
---------- ---------- ---------- ------------------------ ---------- -------------------
6 31 234 NONE 2479 2011-10-07 06:32:47Elapsed: 00:00:00.01
SQL> /
KTUXEUSN KTUXESLT KTUXESQN KTUXECFL KTUXESIZ SYSDATE
---------- ---------- ---------- ------------------------ ---------- -------------------
6 31 234 NONE 0 2011-10-07 06:32:52Elapsed: 00:00:00.01
SQL>
SQL> select 38912/((3616-2479)/2) from dual;
38912/((3616-2479)/2)
---------------------
68.4467898
Elapsed: 00:00:00.01
SQL>通过我计算发现，应该是需要68.44s才能完成rollback操作，但是为什么实际上46.53s就完成了呢？#####再次进行相同的测试
SQL> delete from ht1;
1022976 rows deleted.
Elapsed: 00:01:31.96
SQL> rollback;
Rollback complete.
Elapsed: 00:00:36.51
SQL>---另一session窗口
SQL> select XIDUSN,XIDSLOT,XIDSQN,NAME,START_UBASQN,START_UBAREC from v$transaction;
XIDUSN XIDSLOT XIDSQN NAME START_UBASQN START_UBAREC
---------- ---------- ---------- ------------------------- ------------ ------------
2 13 217 207 55Elapsed: 00:00:00.01
SQL> select KTUXEUSN, KTUXESLT, KTUXESQN, KTUXECFL, KTUXESIZ, sysdate
2 from x$ktuxe
3 where KTUXEUSN = 2
4 and KTUXESLT = 13;
KTUXEUSN KTUXESLT KTUXESQN KTUXECFL KTUXESIZ SYSDATE
---------- ---------- ---------- ------------------------ ---------- -------------------
2 13 217 NONE 38913 2011-10-07 06:55:36Elapsed: 00:00:00.01
SQL> /
KTUXEUSN KTUXESLT KTUXESQN KTUXECFL KTUXESIZ SYSDATE
---------- ---------- ---------- ------------------------ ---------- -------------------
2 13 217 NONE 32721 2011-10-07 06:55:54Elapsed: 00:00:00.00
SQL> /
KTUXEUSN KTUXESLT KTUXESQN KTUXECFL KTUXESIZ SYSDATE
---------- ---------- ---------- ------------------------ ---------- -------------------
2 13 217 NONE 29825 2011-10-07 06:55:55Elapsed: 00:00:00.00
SQL> /
KTUXEUSN KTUXESLT KTUXESQN KTUXECFL KTUXESIZ SYSDATE
---------- ---------- ---------- ------------------------ ---------- -------------------
2 13 217 NONE 29195 2011-10-07 06:55:57Elapsed: 00:00:00.01
SQL> /
KTUXEUSN KTUXESLT KTUXESQN KTUXECFL KTUXESIZ SYSDATE
---------- ---------- ---------- ------------------------ ---------- -------------------
2 13 217 NONE 25293 2011-10-07 06:56:00Elapsed: 00:00:00.00
SQL> /
KTUXEUSN KTUXESLT KTUXESQN KTUXECFL KTUXESIZ SYSDATE
---------- ---------- ---------- ------------------------ ---------- -------------------
2 13 217 NONE 22288 2011-10-07 06:56:02Elapsed: 00:00:00.00
SQL> /
KTUXEUSN KTUXESLT KTUXESQN KTUXECFL KTUXESIZ SYSDATE
---------- ---------- ---------- ------------------------ ---------- -------------------
2 13 217 NONE 21288 2011-10-07 06:56:04Elapsed: 00:00:00.00
SQL> /
KTUXEUSN KTUXESLT KTUXESQN KTUXECFL KTUXESIZ SYSDATE
---------- ---------- ---------- ------------------------ ---------- -------------------
2 13 217 NONE 18512 2011-10-07 06:56:05Elapsed: 00:00:00.01
SQL> /
KTUXEUSN KTUXESLT KTUXESQN KTUXECFL KTUXESIZ SYSDATE
---------- ---------- ---------- ------------------------ ---------- -------------------
2 13 217 NONE 17643 2011-10-07 06:56:07Elapsed: 00:00:00.00
SQL> /
KTUXEUSN KTUXESLT KTUXESQN KTUXECFL KTUXESIZ SYSDATE
---------- ---------- ---------- ------------------------ ---------- -------------------
2 13 217 NONE 16880 2011-10-07 06:56:08Elapsed: 00:00:00.00
SQL> select * from v$fast_start_transactions;
no rows selected
Elapsed: 00:00:00.00
SQL> select * from v$fast_start_servers;
no rows selectedElapsed: 00:00:00.00
SQL> /no rows selected
Elapsed: 00:00:00.00根据前面的时间数据，我分别计算出2个值如下1238和1102，然后再根据该值取平均值，如下；
SQL> select 1238+1102 from dual;
1238+1102
----------
2340
SQL> select 2340/2 from dual;
2340/2
----------
1170
SQL> select 38913/1170 from dual;
38913/1170
----------
33.2589744
SQL>我们来看看此次的rollback时间，如下：
SQL> show user
USER is "ROGER"
SQL>
SQL> delete from ht1;
1022976 rows deleted.
Elapsed: 00:01:31.96
SQL> rollback;Rollback complete.
Elapsed: 00:00:36.51
我们可以看到，已经非常的接近了，因为前面的时间计算，其实还存在一定的误差，从数学的角度来说，
要想更加精确，需要把时间扩大，进行多次采集然后计算平均值，那样可能就更加接近实际值了。最后需要做一点补充的是，关于x$ktuxe大家可以参考我以前的一个笔记，简略信息如下：
ktuxc,其实并不神秘，跟一个x$表相关，即如下x$表：x$ktuxe
[K]ernel [T]ransaction [U]ndo transaction [E]ntry我们知道，在平常所遇到的数据库故障中，跟undo相关的太多了，基本上ora-4xxx ~都跟undo有种很紧密的联系比如大家所熟知的ora-4193、ora-4000、ora-4194等等。 这里我主要简单的分析下ktuxe的结构，其实关于ktuxe，
还有一个很重要的地方，那就是无法通过v$tranactions查到的死事物，我们可以通过x$ktuxe来获取。那么ktuxe，ktuxc结构到底多大呢？换句话说，在整个block中，占据了多个个byte呢？ 如下：COMPONEN TYPE DESCRIPTION TYPE_SIZE
-------- -------- -------------------------------- ----------
S EWORD EITHER WORD 4
S EB1 EITHER BYTE 1 1
S EB2 EITHER BYTE 2 2
S EB4 EITHER BYTE 4 4
S UWORD UNSIGNED WORD 4
S UB1 UNSIGNED BYTE 1 1
S UB2 UNSIGNED BYTE 2 2
S UB4 UNSIGNED BYTE 4 4
S SWORD SIGNED WORD 4
S SB1 SIGNED BYTE 1 1
S SB2 SIGNED BYTE 2 2
S SB4 SIGNED BYTE 4 4
S BOOLEAN BOOLEAN 4
S FLOAT FLOAT 4
S DOUBLE DOUBLE 8
S SIZE_T SIZE_T 4
S DSIZE_T DSIZE_T 4
S PTR_T PTR_T 4
K KDBA DATABASE BLOCK ADDRESS 4
K KTNO TABLE NUMBER IN CLUSTER 1
K KSCN SYSTEM COMMIT NUMBER 8
K KXID TRANSACTION ID 8
K KUBA UNDO ADDRESS 8
KCB KCBH BLOCK COMMON HEADER 20
KTB KTBIT TRANSACTION VARIABLE HEADER 24
KTB KTBBH TRANSACTION FIXED HEADER 48
KTB KTBBH_BS TRANSACTION BLOCK BITMAP SEGMENT 8
KDB KDBH DATA HEADER 14
KDB KDBT TABLE DIRECTORY ENTRY 4
KTE KTECT EXTENT CONTROL 44
KTE KTECH EXTENT CONTROL 72
KTE KTETB EXTENT TABLE 8
KTS KTSHC SEGMENT HEADER 8
KTS KTSFS SEGMENT FREE SPACE LIST 20
KTS KTSPHW PAGE TABLE SEGMENT HWM 60
KTS KTSPHC PAGE TABLE SEGMENT HEADER 112
KTS KTSPFHC LEVEL 1 BITMAP BLOCK HEADER 184
KTS KTSPSHC LEVEL 2 BITMAP BLOCK HEADER 96
KTS KTSPTHC LEVEL 3 BITMAP BLOCK HEADER 88
KTU KTUBH UNDO HEADER 16
KTU KTUXE UNDO TRANSACTION ENTRY 40 ---- 跟ktuxc相关
KTU KTUXC UNDO TRANSACTION CONTROL 104 ---- 这里是我们这里需要关注的地方 （占据了104个byte）
KDX KDXCO INDEX HEADER 16
KDX KDXLE INDEX LEAF HEADER 32
KDX KDXBR INDEX BRANCH HEADER 24
BBED> p ktuxc
struct ktuxc, 104 bytes @4148 （通过bbed我们可以发现，确定是占据了104个byte）
struct ktuxcscn, 8 bytes @4148
ub4 kscnbas @4148 0x001564b5 ---scn值
ub2 kscnwrp @4152 0x0000
struct ktuxcuba, 8 bytes @4156 --UBA值 （有如下3部分组成）
ub4 kubadba @4156 0x00400181 --dba（转换后为file 1 block 385）
ub2 kubaseq @4160 0x0068
ub1 kubarec @4162 0x0f --Last Entry in UNDO record map
sb2 ktuxcflg @4164 1 (KTUXCFSK) --表示inactive
ub2 ktuxcseq @4166 0x0068
sb2 ktuxcnfb @4168 1
ub4 ktuxcinc @4172 0x00000000
sb2 ktuxcchd @4176 30
sb2 ktuxcctl @4178 22 ---这里的部分内容 目前我还没搞清楚是啥意思
ub2 ktuxcmgc @4180 0x8002
ub4 ktuxcopt @4188 0x7ffffffe
struct ktuxcfbp[0], 12 bytes @4192
struct ktufbuba, 8 bytes @4192
ub4 kubadba @4192 0x00400181
ub2 kubaseq @4196 0x0068
ub1 kubarec @4198 0x0f
sb2 ktufbext @4200 2
sb2 ktufbspc @4202 4280
struct ktuxcfbp[1], 12 bytes @4204
struct ktufbuba, 8 bytes @4204
ub4 kubadba @4204 0x00000000
ub2 kubaseq @4208 0x0065
ub1 kubarec @4210 0x02
sb2 ktufbext @4212 5
sb2 ktufbspc @4214 7886
struct ktuxcfbp[2], 12 bytes @4216
struct ktufbuba, 8 bytes @4216
ub4 kubadba @4216 0x00000000
ub2 kubaseq @4220 0x003e
ub1 kubarec @4222 0x25
sb2 ktufbext @4224 2
sb2 ktufbspc @4226 464
struct ktuxcfbp[3], 12 bytes @4228
struct ktufbuba, 8 bytes @4228
ub4 kubadba @4228 0x00000000
ub2 kubaseq @4232 0x003e
ub1 kubarec @4234 0x08
sb2 ktufbext @4236 2
sb2 ktufbspc @4238 7130
struct ktuxcfbp[4], 12 bytes @4240
struct ktufbuba, 8 bytes @4240
ub4 kubadba @4240 0x00000000
ub2 kubaseq @4244 0x0000
ub1 kubarec @4246 0x00
sb2 ktufbext @4248 0
sb2 ktufbspc @4250 0
从上面信息，我们可以发现最后一次使用的undo block是 file 1 block 385。 下面来看看ktuxe的情况下面我们来看看x$ktuxe的结构：
SQL> desc x$ktuxe
Name Null? Type
------------------ -------- ----------------------------
ADDR RAW(4)
INDX NUMBER
INST_ID NUMBER
KTUXEUSN NUMBER --undo seq number
KTUXESLT NUMBER --slot 即为事务槽号
KTUXESQN NUMBER --sequence号
KTUXERDBF NUMBER --文件号 即为file id
KTUXERDBB NUMBER --block 号
KTUXESCNB NUMBER --SCN base for prepare/commit
KTUXESCNW NUMBER --SCN wrap for prepare/commit
KTUXESTA VARCHAR2(16) --事务状态 （我所知道的应该是有3种 action,inaction,dead)
KTUXECFL VARCHAR2(24) --事务标志
KTUXEUEL NUMBER --这里根据我猜测，应该是指用于存放事务的一个列表
KTUXEDDBF NUMBER --file id
KTUXEDDBB NUMBER --block number
KTUXEPUSN NUMBER --parent usn number
KTUXEPSLT NUMBER --parent solt number
KTUXEPSQN NUMBER --parent seq#
KTUXESIZ NUMBER --用于该事务有多少个undo block（单位是block）这里我只想说明一点的是，注意KTUXESIZ的单位是block，而不是byte。
本文的重点不是来讲述这个x$表的用途，而是像详细说明parallel rollback 的一些东西，
这里有点要说明的是，rollback分为两种，如下：
1. parallel rollback 即并行回滚
2. Serial rollback 即串行回滚当初始化参数fast_start_parallel_rollback设置为false以后，即为串行回滚，否则为并行回滚。
我们知道并行回滚是oracle 8i引入的一个特性，那么必然就有它的优势，但是我google了一下，
找到了老白的帖子，说某些情况下并行恢复会非常的慢，但是没有说具体是那些情况下，这点较为
遗憾。我这里由于是单表所以模拟的时候没没有发现parallel rollback进程，虽然说参数是默认值。
总的来说，不管是使用并行回滚还是串行回滚，我们都可以通过上面的方法来进行估算具体的回滚时间。通过所掌握的知识来看，我猜测可能在如下的情况下parallel rollback可能会更慢：
1. 相关的操作正常情况下走index，而如果是parallel，那么将走全表扫描，所以会更慢;
2. 存在相关争用的情况下。当时，另外我们还可以同调整_cleanup_rollback_entries来加快恢复进度，在某些情况下。
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/29371470/viewspace-2637209/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/29371470/viewspace-2637209/