parallel rollback参数总结

最新推荐文章于 2023-09-03 15:55:53 发布

coujiongyong0208

最新推荐文章于 2023-09-03 15:55:53 发布

阅读量504

点赞数

文章标签：数据库

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/

coujiongyong0208

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
parallel rollback参数总结

fast_start_parallel_rollback该参数是oracle 8i引入的，详细信息如下表所示：Version Parameter Type Modifiable 11.1.0.7 f...
复制链接

扫一扫