关于回滚段的探讨（推出第一篇文章）

dplorer

谢谢biti,一时记不得在那看过？这个问题我也有疑问？继续关注！
回到delay block cleanout,要是那样的话，若rollback分区数据被覆盖，其不是查询几星期以前提交的数据也会出ORACLE ORA-01555
,这好像与ORACLE的实际情况不符。
另外，RESTART INSTANCE有会如何？改变的块依旧没有CLEANOUT吗？

biti_rainy

最初由 dplorer 发布
[B]谢谢biti,一时记不得在那看过？这个问题我也有疑问？继续关注！
回到delay block cleanout,要是那样的话，若rollback分区数据被覆盖，其不是查询几星期以前提交的数据也会出ORACLE ORA-01555
,这好像与ORACLE的实际情况不符。
另外，RESTART INSTANCE有会如何？改变的块依旧没有CLEANOUT吗？ [/B]

只要数据库能判断 commit SCN  小于查询 SCN ,则就不会出现1555错误
这个commit SCN 怎么确定呢？首先看该事务的回滚段信息是否存在，若存在好判断，若已经不存在，则该事务肯定已经提交并且早于当前回滚段中的最小SCN.
而这个时候发生的cleanout 需要给一个commit scn(准确的commit scn已经找不着了),这 是由 回滚段头的 control  SCN 确定的，这个control SCN 也就是 回滚段中记录的最早的事务的SCN .也就是说，若真实commit SCN 小于这个 comtrol  SCN 并且 查询SCN 大于 control  SCN ,则数据库可以确信该数据认为该查询可以接受该数据，但该数据的commit SCN 却是已经被覆盖了找不回来了，于是数据库把当前回滚段的control SCN 当作该事务的commit  SCN 写入block，作为 block  cleanout 的SCN.这不会对今后的数据库的任何查询和事务构成障碍

那这里有个关键的问题就是，若查询时间太长，回滚段已经被覆盖过了，出现实际 commit SCN and 查询 SCN 都小于 control SCN ,则数据库无法判断查询是否能接受该数据，则这样的情况下由于block  cleanout产生了 1555 错误

dplorer

非常精彩！你对oracle internal的了解让我佩服！
关于wraps,asktom中有这样一段话
The WRAPS column indicate the number of times the rollback segment wrapped to another extent to serve the transaction.  If this number is significant then you need to increase the extent size of the rollback segment.  WRAPS is sort of a "bad" name as it implies a total wrap around but it is the measure of how many times we SPANNED extents.

biti_rainy

you  are  right

wraps指的是从一个 extents 过度到另一个extents的时候的次数

oracle文档的描述太含糊了：WRAPS
NUMBER
Number of times rollback segment is wrapped
   很容易有歧义

我在这里以前没有测试造成的误导表示歉意  

测试过程如下：
SQL>  select usn,extents,rssize,writes,wraps from v$rollstat;

       USN    EXTENTS     RSSIZE     WRITES      WRAPS
---------- ---------- ---------- ---------- ----------
         0          5     401408       4410          0
         1          8    4186112     140004          0
         2          8    4186112       1406          0
         3          8    4186112        160          0
         4          8    4186112        264          0
         5          8    4186112       6340          0
         6          8    4186112         54          0
         7          8    4186112         54          0

8 rows selected.

SQL> delete from t;

34738 rows deleted.

SQL>  select usn,extents,rssize,writes,wraps from v$rollstat;

       USN    EXTENTS     RSSIZE     WRITES      WRAPS
---------- ---------- ---------- ---------- ----------
         0          5     401408       4410          0
         1         16    8380416    7596264         15
         2          8    4186112       1406          0
         3          8    4186112        160          0
         4          8    4186112        264          0
         5          8    4186112       6340          0
         6          8    4186112         54          0
         7          8    4186112         54          0

8 rows selected.

tolywang

可以阿 ， 改一下名称吧， 改称英文试一下 。

chenjun117

好文!!!
拜讀中~~

hilbert_2003

呵呵 老大的文章一定拜读～

alphah

收藏先

biti_rainy

最初由 Kamus 发布
[B]对于文章中的一点提出疑问
biti提到在x$bh视图中11+2*USN为回滚段头，12+2*USN为回滚段块
但是我的9201自动回滚段管理的库中
却是15+2*USN为回滚段头，16+2*USN为回滚段快

这个应该不是一个定值？跟数据库版本？block大小？回滚段的管理方式？有关？ [/B]

SQL> select * from v$waitstat;

CLASS                   COUNT       TIME
------------------ ---------- ----------
data block                  3         13
sort block                  0          0
save undo block             0          0
segment header              0          0
save undo header            0          0
free list                   0          0
extent map                  0          0
1st level bmb               0          0
2nd level bmb               0          0
3rd level bmb               0          0
bitmap block                0          0

CLASS                   COUNT       TIME
------------------ ---------- ----------
bitmap index block          0          0
file header block           0          0
unused                      0          0
system undo header          0          0
system undo block           0          0
undo header                40        247
undo block                  0          0

18 rows selected.

你照着数下来就发现第17条开始是 undo  header

这个编号是随着版本的变化而变化的

yjf6660

老大就是老大，以您为师！