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

biti_rainy

最初由 Kamus 发布
[B][php]
SQL> select USN,EXTENTS,RSSIZE,WRITES from v$rollstat;

       USN    EXTENTS     RSSIZE     WRITES
---------- ---------- ---------- ----------
         0          6     385024       4600
         1         12   10608640    9959586
         2          3    1171456     138380
         3          8    6414336    5601608
         4          3    1171456     309926
         5          3    1171456     138198
         6         11    9560064    8870666
         7         12   10608640    9129036
         8          7    5365760    4698838
         9          3    1171456     127932
        10          3    1171456     126290

11 rows selected

Executed in 0.07 seconds

SQL> select count(*),class from x$bh where ts#=1 and file#=2 and class>13 group by class;

  COUNT(*)      CLASS
---------- ----------
         1         17
        18         18
         1         19
        19         20
         1         21
        18         22
         1         23
        39         24
         1         25
        18         26
         1         27
       581         28
         1         29
       191         30
         1         31
        19         32
         1         33
        17         34
         1         35
        17         36

20 rows selected

Executed in 0.09 seconds

[/php]

这个现象怎么解释？
USN=4的回滚段只有3个extent，但是在x$bh中却有39个block？
而USN=1的回滚段有12个extent，却只有18个bock？

x$bh中显示的是dirty data的block？ [/B]

x$bh 中是被使用过的还在内存中的 buffer 数量，而 extent 仅仅是在文件中分配的extent个数

suno

看了几遍，觉得很好

ffyffy

最初由 biti_rainy 发布
[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 错误 [/B]

拜读了biti的力作后，有很多疑问，有时间一并问了，现在问一个有关delay cleanout的问题，请问物理数据文件的block 中是否有commit SCN的信息，如果有不是可以从物理文件的block中读出来就可以了？另不知为什么oracle会要直接写数据文件而不更新data buffer，企不是自找麻烦？

ffyffy

哪位大虾能答一下，这个论坛总不能搞得都是专家啦。应该提倡热情回答后进者的问题，哪怕是初级的。这样这个论坛才更有活力、更有吸引力、更有号召力、更有亲和力!

enhydraboy

最初由 kkevint 发布
[B]hai, i cann't print , can u let me know how to crack it.

thanks. [/B]

I can print.Why u want to crack it???????

fxptiger

真是好人亚

歆歆

学习

leikymon

正在阅读中，感觉很不错，帮助我理清了一些思路！感谢biti_rainy提供好文章！！

axman

收藏ing...看了再回来看贴.

raddisonlee

谢谢BITI，有出第二集？